Split Tunneling Question on AsusWrt Merlin

[Viktor Jaep]

However, if you are using a Windows laptop, then I recommend you use WinSCP

Oh wow... yep, WinSCP is a must-have... thank you -- that worked great!

/jffs/scripts/openvpn-event

No you use the VPN GUI as normal, and vpnrouting.sh will now automatically find/execute openvpn-event who will then execute vpnclient1-route-up.sh

So I now show the 2 files under the jffs/scripts folder:

openvpn-event (you didn't specify, but does this need a .sh on it as well?)
vpnclient1-route-up.sh

Initially I had a .sh on the openvpn-event file, but when I didn't see any change after restarting, I removed the .sh. I even ran: chmod a+rx /jffs/scripts/* for good measure.

So I rebooted, stopped, started, stopped and restarted the VPN service for client 1... checked the ip rule, ip route show table 111 and ip route statements, and they have not changed from before. Bah...

 

[Martineau]

So I rebooted, stopped, started, stopped and restarted the VPN service for client 1... checked the ip rule, ip route show table 111 and ip route statements, and they have not changed from before. Bah...

There should be a specific 'Debug' message from the 'vpnclient1-route-up' script, together with 'openvpn-event' messages in Syslog?

 

[Viktor Jaep]

There should be a 'Debug' message in Syslog?

Jun 25 11:01:35 openvpn-event[2875]: Script not defined for event: vpnclient1-route-up

 

[Martineau]

Jun 25 11:01:35 openvpn-event[2875]: Script not defined for event: vpnclient1-route-up

so...remove the '.sh' suffix.

 

[Viktor Jaep]

so...remove the '.sh' suffix.

Yes! Progress!!

Jun 25 11:59:10 custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1556 100.64.0.3 255.255.248.0 init)
....
Jun 25 11:59:35 custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1556 100.64.0.3 )
Jun 25 11:59:35 Debug: Hack to fix missing 'default' statement in table 111 ovpnc1 1

However, when I check the "ip route show table 111", it still doesn't show anything new.

 

[RMerlin]

Make sure your server is configured to push a default route (and not just a redirect-gateway def1 setting, because all this does is set up two pseudo routes that get removed by vpnrouting).

 

[Martineau]

Yes! Progress!!

Jun 25 11:59:10 custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1556 100.64.0.3 255.255.248.0 init)
....
Jun 25 11:59:35 custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1556 100.64.0.3 )
Jun 25 11:59:35 Debug: Hack to fix missing 'default' statement in table 111 ovpnc1 1

However, when I check the "ip route show table 111", it still doesn't show anything new.

OK, The vpnclient1-route-up script prints the following diagnostic message containing three variables to syslog:

Debug" "Hack to fix missing 'default' statement in table 111" $route_vpn_gateway $VPN_TBL $VPN_FORCE

but the message actually printed was:

Debug: Hack to fix missing 'default' statement in table 111 ovpnc1 1

clearly it only prints two variable values i.e. the 2nd and 3rd 'ovpnc1' and '1' i.e. there is no expected I/P address shown for the 1st variable '$route_vpn_gateway'

So it looks like we have found the issue although sadly not the cause

Can you modify vpnclient1-route-up

#!/bin/sh
logger -st "Debug" "Hack to fix missing 'default' statement in table 111" [$@] $route_vpn_gateway $VPN_TBL $VPN_FORCE

ip route add default via $4 dev tun11 table 111

and retry?

 

[Viktor Jaep]

Can you modify vpnclient1-route-up

#!/bin/sh
logger -st "Debug" "Hack to fix missing 'default' statement in table 111" [$@] $route_vpn_gateway $VPN_TBL $VPN_FORCE

ip route add default via $4 dev tun11 table 111

and retry?

You are amazing, Martineau! Looks like that did the trick!

Jun 25 12:34:04 Debug: Hack to fix missing 'default' statement in table 111 [tun11 1500 1556 100.64.0.3] ovpnc1 1
J

Now, when I check the ip route show table 111, I'm seeing a default entry in there... and my iplookup is now correctly showing my VPN ip as my public IP! You rock!

Question: When I upgrade to the next release of Merlin, will I need to keep these scripts handy in order to upload them each time a new version is flashed?

Thank you!
Viktor

 

[Martineau]

You are amazing, Martineau! Looks like that did the trick!

Jun 25 12:34:04 Debug: Hack to fix missing 'default' statement in table 111 [tun11 1500 1556 100.64.0.3] ovpnc1 1
J

Now, when I check the ip route show table 111, I'm seeing a default entry in there... and my iplookup is now correctly showing my VPN ip as my public IP! You rock!

Question: When I upgrade to the next release of Merlin, will I need to keep these scripts handy in order to upload them each time a new version is flashed?

Thank you!
Viktor

Well it depends!

Do you want to follow the author's advice...
https://www.snbforums.com/threads/s...on-on-asuswrt-merlin.39824/page-2#post-332442

i.e. chastise your VPN provider and get them to change what I/Ps they should push i.e. real vs. virtual!

Clearly my crude end-user written hack seemingly works for you since we know that the default entry is currently missing, but in future releases, it would be prudent to ensure vpnclientX-route-up doesn't attempt to add a duplicate directive!

Whilst vpnrouting.sh remains flawed, the author again may deem that it does not warrant a code review to ensure it should always validate that a command executed correctly or check that the expected mandatory parameters are valid, although time/resource permitting v380.67 may include a fix (or at least a WARNING) and potentially also add the six static RPDB fwmark rules!.

P.S. Just out of curiosity, who is your VPN provider?

 

[Viktor Jaep]

Well it depends!

Do you want to follow the author's advice...
https://www.snbforums.com/threads/s...on-on-asuswrt-merlin.39824/page-2#post-332442

i.e. chastise your VPN provider and get them to change what I/Ps they should push i.e. real vs. virtual!

I can certainly bounce it off them and see if they can change their ways? So I basically need to ask them why they're not passing along a default gateway during negotiation, right?

Clearly my crude end-user written hack seemingly works for you since we know that the default entry is currently missing, but in future releases, it would be prudent to ensure vpnclientX-route-up doesn't attempt to add a duplicate directive!

Whilst vpnrouting.sh remains flawed, the author again may deem that it does not warrant a code review to ensure it should always validate that a command executed correctly or check that the desired parameters are valid, although time/resource permitting v380.67 may include a fix (or at least a WARNING) and potentially also add the six static RPDB fwmark rules!.

P.S. Just out of curiosity, who is your VPN provider?

My VPN provider is StrongVPN... I also used PureVPN in the past, however I'm starting to shy away from them as their parent company is Chinese-based.

Thanks,
Viktor

 

[Martineau]

I can certainly bounce it off them and see if they can change their ways? So I basically need to ask them why they're not passing along a default gateway during negotiation, right

Technically the two pseudo routes (that unfortunately must be removed from table 254 by vpnrouting.sh in order to provide Selective routing using Policy Rules) that they currently push:

0.0.0.0/1
128.0.0.0/1

is the ideal solution.

The two routes are a clever trick to overrule the default route on the (normally non-router) end-user device (say a laptop) so that ALL the traffic is sent through the tunnel instead of to the default LAN gateway. The advantage of this method is that the original default gateway on the device is left intact. When the VPN is disconnected, the original gateway address automatically takes over again. If we would simply use redirect-gateway, there is a risk that the default gateway is lost i.e. not restored when the VPN is disconnected, resulting in a complete loss of network connectivity on the laptop - not good!

So be aware the VPN vendor is not obliged to 'comply' with your query even if you do pay for the service!

 

[Viktor Jaep]

So be aware the VPN vendor is not obliged to 'comply' with your query even if you do pay for the service!

Thanks so much for the extra detail, Martineau... I'll bounce it off of them! Lets hope they are willing to change their ways...

Thanks again for all your help and assistance on this!

 

[RMerlin]

although time/resource permitting v380.67 may include a fix

Sure, if someone can explain in a concise way what the problem is, and a recommended fix. So far, every thread that discussed policy-based routing went on for 3+ pages long of scriptlets and debug output. Unfortunately, I don't really have the time to go through every single of these complicated threads and spend tinme analyzing all the details being discussed in them and spread over dozens of separate posts. This forum has 30+ posts per day, and some discussions are fairly technical in details - not the kind of post you can just spend 30 secs reading and immediately figure out all the details.

 

[Viktor Jaep]

Sure, if someone can explain in a concise way what the problem is, and a recommended fix. So far, every thread that discussed policy-based routing went on for 3+ pages long of scriptlets and debug output. Unfortunately, I don't really have the time to go through every single of these complicated threads and spend tinme analyzing all the details being discussed in them and spread over dozens of separate posts. This forum has 30+ posts per day, and some discussions are fairly technical in details - not the kind of post you can just spend 30 secs reading and immediately figure out all the details.

Hi Eric -- I'm hoping this helps:

Background: If I run all my traffic over a VPN, my VOIP router loses its connection to its host after a while. It doesn't seem to have problems on the regular WAN. I tried QoS, and some other stuff to keep it alive... nothing seemed to work. So when I found out in all my excitement that the Merlin firmware was able to handle split tunneling, I was all over it. I was trying to create a split tunnel like this:

LocalNetwork 192.168.1.0/24 0.0.0.0 VPN
VoipDevice 192.168.1.100 0.0.0.0 WAN

My VPN provider is through StrongVPN... Each time a connection was made when I switched "redirect internet traffic" to "policy rules", all my traffic would continue to go out over WAN, eventhough the router was indicating that a VPN connection had been made. The TUN/TAP read/write bytes would always just indicate 0, as if nothing was going out across this VPN connection. I just figured that this kind of setup just wasn't going to work, but Martineau believed it would.

So, Martineau helped discover that my default route didn't exist when I ran the "ip route show table 111" command. Apparently my VPN provider isn't passing a default route... so Martineau helped me out by creating a new vpnclient1-route-up script that manually adds the default route using the following:

ip route add default via $4 dev tun11 table 111

Other than complaining to my VPN provider, I'm not sure what else I can do. From your end, perhaps you can check for a gateway, and if one isn't present, that it's able to resort to this method (above) as a backup to still get that gateway added to the routing table? I'm not knowledgeable enough when it comes to manipulating these scripts to know whether this kind of statement would work for others, or if I'm (or StrongVPN is) just special.

I truly appreciate Martineau's help, and your willingness to see if this issue is resolvable from your end!

Thanks,
Viktor

 

[Martineau]

Sure, if someone can explain in a concise way what the problem is, and a recommended fix. So far, every thread that discussed policy-based routing went on for 3+ pages long of scriptlets and debug output. Unfortunately, I don't really have the time to go through every single of these complicated threads and spend tinme analyzing all the details being discussed in them and spread over dozens of separate posts. This forum has 30+ posts per day, and some discussions are fairly technical in details - not the kind of post you can just spend 30 secs reading and immediately figure out all the details.

If the hack is unacceptable, then at least issue an Alert or even fail the initialisation of the VPN connection?

--- /usr/sbin/vpnrouting.sh
+++ /jffs/scripts/vpnrouting.sh
@@ -1,5 +1,7 @@
 #!/bin/sh
 
 @@ -223,7 +249,17 @@
    logger -t "openvpn-routing" "Tunnel re-established, restoring WAN access to clients"
   fi
   ip route del default table $VPN_TBL
+  ########################################################################################## Martineau Hack 4 of 5
+  if [ -z "$route_vpn_gateway" ];then
+   ip route add default via $4 table $VPN_TBL
+   logger -t "openvpn-routing" "NO default-gateway found for client $VPN_UNIT (0.0.0.0/1 and 128.0.0.0/1 ONLY ?) so attempting work-around"
+  else
    ip route add default via $route_vpn_gateway table $VPN_TBL
+  fi
+  if [ -z "$(ip route show table $VPN_TBL | grep -E "^.*default")" ];then
+   logger -t "openvpn-routing" "***ERROR client $VPN_UNIT routing table is FORCED via WAN"
+  fi
+  ##########################################################################################
  fi
 
  if [ "$route_net_gateway" != "" ]

 

[RMerlin]

Thanks for the info. I'll try to take a closer look at it this week.

In the mean time, did you try switching policy routing to Policy Rules (Strict)? It behaves slightly differently in how it handles routes when copying them.

Also, can you provide me with a copy of the PUSH options that you get in your Syslog after your client connect? I want to see which options are pushed by StrongVPN.

Thanks!

 

[RMerlin]

If the hack is unacceptable, then at least issue an Alert or even fail the initialisation of the VPN connection?

One of the things I was considering while I was working on the new Policy (Strict mode) a few months ago was copying the two routes created by redirect-gateway def1 into the client tables, instead of just completely dropping them. Assuming they are at the end of the client table, they shouldn't interfere with user-defined policies. That could be a way of dealing with providers who rely on these two routes instead of a default gateway.

 

[Viktor Jaep]

Thanks for the info. I'll try to take a closer look at it this week.

In the mean time, did you try switching policy routing to Policy Rules (Strict)? It behaves slightly differently in how it handles routes when copying them.

Also, can you provide me with a copy of the PUSH options that you get in your Syslog after your client connect? I want to see which options are pushed by StrongVPN.

Thanks!

Hi Eric... I believe I did try the strict policy rules while experimenting, and they behaved the same way... ie. all traffic just going out through the WAN.

Here's a copy of the PUSH statement:

Jun 23 11:16:34 openvpn[12258]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 171.225.236.244,dhcp-option DNS 215.285.237.194,ping 1,ping-restart 60,route-gateway 101.63.2.1,topology subnet,socket-flags TCP_NODELAY,ifconfig 101.63.2.3 255.255.248.0'

...which is strange, as it does seem to include a "route-gateway"... unless that's not the same thing that we've been talking about?

Thank you,
Viktor

 

[Martineau]

Sure, if someone can explain in a concise way what the problem is, and a recommended fix. So far, every thread that discussed policy-based routing went on for 3+ pages long of scriptlets and debug output. Unfortunately, I don't really have the time to go through every single of these complicated threads and spend tinme analyzing all the details being discussed in them and spread over dozens of separate posts. This forum has 30+ posts per day, and some discussions are fairly technical in details - not the kind of post you can just spend 30 secs reading and immediately figure out all the details.

Reference the continuing esoteric use of Github as an alternative to this forum:
https://github.com/RMerl/asuswrt-merlin/issues

There are tickets that were opened on GitHub (which following exchange conversations between yourself and the submitter) that could benefit this forum's users by possibly appearing as a 'sticky' thread to reduce submission of duplicates?

e.g. Tickets that are marked 'Enhancement'
https://github.com/RMerl/asuswrt-merlin/issues/1178

Clearly you need to devote additional time to review/reject the separate GitHub repository tickets that unfortunately are probably only viewed by a select few.

So, acknowledging the increase in your workload (outside of this 'hobby'), given your feedback about how difficult it is for you to deduce what is actually relevant amongst the many pages of 'irrelevant dross' in the threads, ..........a point of clarification, if I may, regarding the formal reporting of issues/bugs and requesting support in general for your firmware.

What is your official stance/preference on how future issue reporting/enhancement requests are formally submitted?


P.S. I noticed that for this ticket
https://github.com/RMerl/asuswrt-merlin/issues/1380

you referred the Github submitter to this thread for 'resolution',

 

[RMerlin]

Regardless of whether it's posted on the forums or on Github, a bug report that isn't concise will have a chance of being skipped. I didn't invent anything here, it's just a basic rule of development.

There are tickets that were opened on GitHub (which following exchange conversations between yourself and the submitter) that could benefit this forum's users by possibly appearing as a 'sticky' thread to reduce submission of duplicates?

The thing with sticky threads is, once a forum has more than a few of them, they get skipped altogether. Look at the DD-WRT Broadcom forum for instance. No one reads them anymore because there are too many of them, and some of them are so long that they are skipped altogether. This is why I keep them to a minimum here. And when a new one is added, nobody notices that there are now 10 sticky posts instead of just 9.

To remain useful, sticky posts must remain to an essential minimum.

Clearly you need to devote additional time to review/reject the separate GitHub repository tickets that unfortunately are probably only viewed by a select few.

I don't have "additional time" to offer. The Github tracker is already requiring a lot of my timee, be it by people who did no troubleshooting at all and directly posted to Github about their issue, or those who flat out use Github for support requests, despite the Github's main README.md stating not to do so. Too many times I have devoted entire evenings trying to chase down the reports of one single report, to discover that the issue was the user's configuration, that he failed to provide basic information (even on these forums, how many times do we have to ask basic questions such as "what router model do you have?", or that he forgot to mention that he was using custom scripts affecting the basic behaviour of the router. I once disabled the Github issue tracker because of this, and decided to re-enable it last year. It's once again becoming more problematic than useful, and I'm still debating what to do with it. In the mean time, entries are taking longer than before in being looked upon. And I can't devote any more time to it. Globally, I'm probably devoting around 15+ hours a week to this project (rough estimate). That grows to over 25 hours during the week of a new release. If it's not enough, then people will have to accept it as it is. This project has long outgrown the ability of one single individual to deal with everything on his own. This is why 1) I refer most support requests to these forums, for the community to sort through configuration issues 2) I need clear and concise bug reports if they actually have a good chance of being a genuine bug.

I already spend more time than many other software developers with a similar userbase size trying to keep up with the volume of communications I get, and actively participating in these forums. I had 20 mins to devote to my morning forum scan before leaving for the office this morning, and I just spent them on this one discussion. So don't ask me to devote more time, as if it was an infinite resource, or as if I wasn't devoting any time to this already - I'm already giving all I can offer in terms of time, more than I even should.

There is a difference between a bug report, and a 3 pages discussion ending in a "it's a bug, ask the author". A bug report has to be concise to be of any use, it's not something I invented, it's just a fact. I don't care if it's done on Github or on these forums, as long as they are clear, and not lost in the middle of a discussion.

P.S. I noticed that for this ticket
https://github.com/RMerl/asuswrt-merlin/issues/1380

you referred the Github submitter to this thread for 'resolution',

And you will see a LOT of them, every time someone comes up with an issue that is either purely a configuration issue, or something that requires actual troubleshooting on the user's end to determine if it has a strong chance of being an actual issue or not. And as the amount of such requests increase, the chances of me turning the user to these forums for proprer troubleshooting will also increase.