[AC87U] Firmware 384.4, VPN rules not working

[Auguste]

Hello,

Since I updated my AC87Uto 384.4, my VPN rules not working. On my device when I check on myip.org, I have the FAI IP and not VPN IP.

What I can do?

Thanks,

 

[Thorton]

87U with VPN, no problems here.

 

[joegreat]

87U with VPN, no problems here.

Same here: Working perfectly fine (coming from version 380.69_2) and using this approach/rules to redirect traffic to VPN connection.

I did a "dirty" update with no factory reset and re-config after the update.

 

[Auguste]

Thanks,

But I found.

In add of VPN rules, I had a DualWan rules to route all traffic of this device on second FAI.

It seems to take over the DualWan rules on VPN rules.

When I deleted Dualwan rules, It's work.

 

[Auguste]

Bad news for me...

I found another problem. The VPN rules works only if dualwan was disabled. When I enable the dualwan, the VPN rules don't work.

 

[Martineau]

Bad news for me...

I found another problem. The VPN rules works only if dualwan was disabled. When I enable the dualwan, the VPN rules don't work.

Script /usr/sbin/vpnrouting.sh will need to be patched

e.g. something like this:

        if [ "$TARGET_ROUTE" = "WAN" ]                                                                                                                
        then
            TARGET_LOOKUP="main"
            WAN_PRIO=$((WAN_PRIO+1))
            RULE_PRIO=$WAN_PRIO
            TARGET_NAME="WAN"
        else
            TARGET_LOOKUP=$VPN_TBL                                                                                                                                                         
            VPN_PRIO=$((VPN_PRIO+1))
            RULE_PRIO=$VPN_PRIO
            TARGET_NAME="VPN client "$VPN_UNIT
        fi

change to

        ########################################################################################## Martineau Hack 2 of 10
        DESC=$(echo $ENTRY | cut -d ">" -f 1)
        #if [ "$TARGET_ROUTE" = "WAN" ]
        if [ "$TARGET_ROUTE" = "WAN" ] || [ "$TARGET_ROUTE" = "WAN0" ] || [ "$TARGET_ROUTE" = "WAN1" ]
        #################################################################################################################
        then
            TARGET_LOOKUP="main"
            TARGET_NAME="WAN"
            ########################################################################################## Martineau Hack 2 of 10
            # Allow GUI tagging for Dual WAN i.e. if DESC contains 'WAN1' then use it! - since drop down is 'WAN' only :-(
            # NOTE: WAN0 entries preferably should precede tagged 'WAN1' entries in the GUI as they will share a single priority
            #       although they will both ALWAYS have a higher priority than the VPN entries
            #if [ "$(nvram get wans_mode) == "lb" )];then  # FO (Failover) / FB (Fallback) / LB (Load-Balancing)
            #if [ -z "$(nvram get wans_dualwan | grep -io "none")" ];then
                if [ "$TARGET_ROUTE" = "WAN1" ] || [ ! -z "$(echo "$DESC" | grep -owi "WAN1" )" ];then
                    TARGET_LOOKUP="200"
                    TARGET_NAME="WAN1"
                    my_logger"Dual-WAN will use WAN1 instead of WAN0 (table main)"
                else
                    if [ "$TARGET_ROUTE" = "WAN0" ];then
                        TARGET_LOOKUP="100"
                    fi
                fi
            #fi
            # v382.xx> for Dual WAN etc. uses prio 100,150,200 and 400 :-(
            #WAN_PRIO=$((WAN_PRIO+1))
            WAN_PRIO=$((WAN_PRIO+OFFSET))
            ################################################################################################################
            RULE_PRIO=$WAN_PRIO
        else
            TARGET_LOOKUP=$VPN_TBL
            ########################################################################################## Martineau Hack 3 of 10
            # v382.xx> for Dual WAN etc. uses prio 100,150,200 and 400 :-(
            #VPN_PRIO=$((VPN_PRIO+1))
            VPN_PRIO=$((VPN_PRIO+OFFSET))
            ################################################################################################################
            RULE_PRIO=$VPN_PRIO
            TARGET_NAME="VPN client "$VPN_UNIT
        fi

and

START_PRIO=$((10000+(200*($VPN_UNIT-1))))
END_PRIO=$(($START_PRIO+199))
WAN_PRIO=$START_PRIO
VPN_PRIO=$(($START_PRIO+100))

change to

########################################################################################## Martineau Hack 9 of 10
# v382.xx> for Dual WAN etc. uses prio 100,150,200 and 400? :-(
FIRMWARE=$(echo $(nvram get buildno) | awk 'BEGIN { FS = "." } {printf("%03d%02d",$1,$2)}')
if [ -z "$(ip rule | grep -Eo -m 1 "^[1|2|4]00:")" ];then
    START_PRIO=$((10000+(200*($VPN_UNIT-1))))
    END_PRIO=$(($START_PRIO+199))
    VPN_PRIO=$(($START_PRIO+100))
    OFFSET=1
else
    START_PRIO=$VPN_UNIT"0"                     # Limit the VPN Clients to a single rule prio
    END_PRIO=$(($START_PRIO+9))
    VPN_PRIO=$(($START_PRIO+5))
    OFFSET=0                                    # Limit the VPN Clients to a single (multiple) rule prio 10,15 and 20,25 etc.
fi
WAN_PRIO=$START_PRIO
#VPN_PRIO=$(($START_PRIO+100))
################################################################################################################

 

[Auguste]

Thanks Mr Martineau, but I'm very sorry to ask another question.

How to patch?

I'm connect by ssh, but it's read-only system, and on https://github.com/RMerl/asuswrt-merlin/wiki/Custom-config-files I can't see vpnrouting.sh able to modify.

Thanks

 

[Martineau]

Thanks Mr Martineau, but I'm very sorry to ask another question.

How to patch?

I'm connect by ssh, but it's read-only system, and on https://github.com/RMerl/asuswrt-merlin/wiki/Custom-config-files I can't see vpnrouting.sh able to modify.

You can always wait until the issue is formally resolved in the next release by the developer?

However, if you prefer not to wait, simply clone the read-only script

cp /usr/sbin/vpnrouting.sh /jffs/scripts/vpnrouting.sh
chmod +x /jffs/scripts/vpnrouting.sh

Use nano/WinSCP etc. to edit /jffs/scripts/vpnrouting.sh

Test your script by mapping your modified script to the original

mount -o bind  /jffs/scripts/vpnrouting.sh /usr/sbin/vpnrouting.sh
df

and restarting the VPN Clients to see if the VPN Clients initialise successfully, and to check if the modifications to the RPDB rules has been made; issue:

ip rule

To revert to the original read-only script simply issue:

umount  /usr/sbin/vpnrouting.sh

NOTE: OpenVPN scripts can also be manually specified by the user either in the GUI or even via the openvpn-event trigger scripts but the mount/umount method is 'global' rather than per client.

 

[Auguste]

Wonderful, it's work! Thanks a lot.

 

[sputnikk]

How does one make the mount -o bind permanent?

 

[Martineau]

How does one make the mount -o bind permanent?

Use init-start

if [ -f /jffs/scripts/vpnrouting.sh ]; then
    logger -st "init-start" "Custom Patching '/usr/sbin/vpnrouting.sh'"
    mount -o bind /jffs/scripts/vpnrouting.sh /usr/sbin/vpnrouting.sh
fi

 

[sputnikk]

Use init-start

if [ -f /jffs/scripts/vpnrouting.sh ]; then
    logger -st "init-start" "Custom Patching '/usr/sbin/vpnrouting.sh'"
    mount -o bind /jffs/scripts/vpnrouting.sh /usr/sbin/vpnrouting.sh
fi

I just got this thing and apparently you're the man for everything I need to do

Thanks for this.

I have to use the local wan0 in my openvpn profile, but it stops working if secondary WAN goes down in LB mode. I have to remove the local wan0 line for it to come up with a single WAN. Any solution?


On an unrelated note: My router locked up the other day, and upon reboot my flash thumb drive was dead. Unreadable/unformattable on any device. Bad luck or is there a known issue?

 

[Martineau]

I have to use the local wan0 in my openvpn profile, but it stops working if secondary WAN goes down in LB mode. I have to remove the local wan0 line for it to come up with a single WAN. Any solution?

Sorry it's been a long day...., not 100% sure I follow your issue?

If Secondary LB WAN goes DOWN, I would expect the Primary LB WAN wan0 to still be valid, clearly Secondary LB WAN wan1 wouldn't ?

On an unrelated note: My router locked up the other day, and upon reboot my flash thumb drive was dead. Unreadable/unformattable on any device. Bad luck or is there a known issue?

There are many posts regarding the reliability of flash drives. Personally I have had random failures - irrespective of price (cheap/expensive) or brand - regardless of where they were used.

However, I've only ever had one that actually died on the router.. IIRC a metal cased HP 4GB drive, but they used to get very hot, so I now try to use a short USB extender to create a thermal air-gap.

 

[sputnikk]

Sorry it's been a long day...., not 100% sure I follow your issue?

If Secondary LB WAN goes DOWN, I would expect the Primary LB WAN wan0 to still be valid, clearly Secondary LB WAN wan1 wouldn't ?

There are many posts regarding the reliability of flash drives. Personally I have had random failures - irrespective of price (cheap/expensive) or brand - regardless of where they were used.

However, I've only ever had one that actually died on the router.. IIRC a metal cased HP 4GB drive, but they used to get very hot, so I now try to use a short USB extender to create a thermal air-gap.

I will test the scenario again and get back with technicals.

Essentially, your script is working for me and forcing routing for VPN out of wan0 - while both WANs are up. This required putting in "local wan0" into my openvpn profile connection.

If however I toggled WAN1 off, routing to OpenVPN failed unless I removed the "local wan0" line from OpenVPN and respun it.

This is from memory a few days ago. I'm in the middle of a VXLAN project and this is my work VPN so I need a few days before I can test again

 

[sputnikk]

Sorry to switch subjects again.

I noticed with this script, I am unable to query remote OpenVPN endpoints from the ASUS Bash shell. WiFi clients hanging off of it can.

This presents a problem for me because dnsmasq is forwading queries for a particular domain to a DNS server across the VPN link, and failing to do so.

Edit: some troubleshooting shows me (where Z.X.C.V is my DNS server across VPN, which works from all wifi clients):

ping Z.X.C.V fails.

specifying an interface directly works however: ping Z.X.C.V -I 192.168.X.1

This makes sense, because I have rules for routing traffic configured in the OpenVPN section:

192.168.X.0/24 routed to Z.X.C.X/24 through VPN.

I'm not sure of the best way to solve this now.

Force dnsmasq to bind to 192.168.X.1 ?

Add 127.0.0.1 to OpenVPN interesting traffic list?

Find the interesting part in this script that would allow localhost to perform the same routing?


Edit #2:

Changing my openvpn interesting routed traffic to source mask: 0.0.0.0/0 instead of 192.168.X.0/24 seemed to fix it. 127.0.0.0/8 did not seem to work.

This makes the network security guy in me cringe, but I "trust" my home network. No dodgy nets or overlaps will happen here, nor do I see the potential for any inbound WAN packets to accidentally traverse into that tunnel. I don't have a single incoming NAT rule defined.