Selective Routing with Asuswrt-Merlin

ionblue · Mar 7, 2014

Martineau said:
RTFM

https://github.com/RMerl/asuswrt-merlin/wiki/User-scripts

I deserved that one. I thought maybe they were already there, but these would be just like what I just created for the vpn stuff.

So this should do it in either one of those scripts:

---
#!/bin/sh

iptables -I FORWARD -i br0 -s 192.168.1.100 -o eth0 -j DROP

exit
---

Correct?

Martineau · Mar 7, 2014

ionblue said:
I deserved that one. I thought maybe they were already there, but these would be just like what I just created for the vpn stuff.

So this should do it in either one of those scripts:

---
#!/bin/sh

iptables -I FORWARD -i br0 -s 192.168.1.100 -o eth0 -j DROP

exit
---

Correct?

You may wish to document in Syslog that your chosen script is about to 'hide' the clandestine activities

i.e. Use of logger statements is very useful when writing scripts to prove they are firing at the appropriate time - and hopefully doing what U intended!

Code:

logger -t "($(basename $0))"  $$ Blocking WAN access for 192.168.1.100......

ionblue · Mar 7, 2014

Awesome! Thank you very much. Now I have to troubleshoot why I lost all wireless communication on the router some time last night.

ionblue · Mar 7, 2014

Martineau said:
So adding

Code:

iptables -I FORWARD -i br0 -s 192.168.1.100 -o eth0 -j DROP

doesn't block outbound access from 192.168.1.100 if you turn off the VPN Client?

Craptastic… This had an unforeseen circumstance. It was dropping ALL traffic even if it was connected to the VPN. Meaning, my other 2 ports that I had routing over the non-vpn connection stopped working as well. Not really sure what that's all about though.

ionblue · Mar 7, 2014

ionblue said:
Craptastic… This had an unforeseen circumstance. It was dropping ALL traffic even if it was connected to the VPN. Meaning, my other 2 ports that I had routing over the non-vpn connection stopped working as well. Not really sure what that's all about though.

Let me expand a bit. For whatever reason the 2 ports that I called out to be expressly routed over the non-vpn connection at all times were being blocked after I ran that DROP command and it was active. That was even though the other 2 were still active.

So either I can't use that as a failsafe or I have something wrong somewhere. Also, should I be expressly using the source IP on those other 2 statements or should that matter since I'm only sending that 1 IP over the VPN connection?

So should it be this:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 563 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 32400 -j MARK --set-mark 12

instead of this:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -i br0 -p tcp --dport 563 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -i br0 -p tcp --dport 32400 -j MARK --set-mark 12

???

And is there a way around the other problem?

Martineau · Mar 9, 2014

ionblue said:
Let me expand a bit. For whatever reason the 2 ports that I called out to be expressly routed over the non-vpn connection at all times were being blocked after I ran that DROP command and it was active. That was even though the other 2 were still active.

So either I can't use that as a failsafe or I have something wrong somewhere. Also, should I be expressly using the source IP on those other 2 statements or should that matter since I'm only sending that 1 IP over the VPN connection?

So should it be this:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 563 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 32400 -j MARK --set-mark 12

instead of this:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -i br0 -p tcp --dport 563 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -i br0 -p tcp --dport 32400 -j MARK --set-mark 12

???

And is there a way around the other problem?

Tagging a device for the VPN and forcing it to ONLY use the WAN works for me using this sequence in the VPN_Select.sh script.
(P.S I am not concerned about accessing the WAN prior to the VPN becoming available!)

Code:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10
iptables -I FORWARD -i br0 -s 192.168.1.100 -o eth0 -j DROP

If I start the command on 192.168.1.100

Code:

   ping   -t   www.ibm.com

it will continue to successfully ping via the VPN (response time is between 600ms-900ms rather than 25ms via WAN)

Checking the selective routing metrics

Code:

   iptables   -t   mangle   -nvL   --line

should confirm that the PKT count for the selected device goes UP proving it is using the VPN

Code:

Chain PREROUTING (policy ACCEPT 4108K packets, 400M bytes)
num   pkts bytes target     prot opt in     out     source          destination
nn    2412  146K MARK       all  --  br0    *       0.0.0.0/0       0.0.0.0/0     source IP range 192.168.1.100-192.168.1.100 MARK set 0xA

If I then stop the VPN then the ping command should stop....

Checking the WAN blocking metrics

Code:

   iptables   -nvL   --line

should show that the PKT count for the selected device goes UP proving it is BLOCKED from using the WAN

Code:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source          destination
nn      64  164K DROP       all  --  br0    eth0    192.168.1.100   0.0.0.0/0

subsequently simply deleting the WAN BLOCKING rule

Code:

   iptable   -D   FORWARD   nn

then allows 192.168.1.100 to browse via the WAN as normal.

In the case of routing everything apart from a couple of ports 563 and 32400 then if we assume by default all traffic bypasses the VPN, in theory the following command (and only requires table 10) should suffice:

i.e. Use VPN for source 192.168.1.100 if port <> 563 and port <> 32400

Code:

   iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -m multiport -p tcp --dport ! 563,32400 -j MARK --set-mark 10

would be the only selective routing command required - but I don't think the ! syntax works for -m multiport :-(

So 3 explicit commands are probably required as U have specified to use both table 10 and table 12.

NOTE: Rule order in iptable Chains is fraught with pitfalls, and is often the cause when an expected rule is prempted :-(

Code:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 32400 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 563 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10

and we can probably be more explicit with the blocking rules (order critical!)

i.e. in firewall-start/nat-start

Code:

iptables -I FORWARD -i br0 -s 192.168.1.100 -o eth0 -j DROP
iptables -I FORWARD -i br0 -s 192.168.1.100 -p tcp --dport 563 -o eth0 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.1.100 -p tcp --dport 32400 -o eth0 -j ACCEPT

Hopefully you can test out if the above works and should be able to see if/when any of the blocking rules are firing.

Also check for iptable duplicates, as firewall-start/nat-start can fire for multiple events/interfaces :-(

So best to have a reboot of the router then manually test the above.

i.e.

Code:

     1. Turn off 192.168.1.00

     2. Enter the 3 blocking rules
    
     3. Turn on 192.168.1.100 

        Confirm that 192.168.1.100 can ONLY access port 563 or 32400 via the WAN

        Start the following (hopfully it should timeout)

           ping   -t   www.ibm.com    
     
     4. Start VPN

     5. Enter the three MARK commands (if they are not already in the VPN_Select.sh script)

     6. Confirm that 192.168.1.100 is using the VPN for all traffic except ports 563 and 32400

        The ping command should now show success.

     7. Stop VPN

        Confirm that 192.168.1.100 can only access port 563 or 32400 via the WAN

        The ping command should show timeout
         
     8. Start VPN

        The ping command should resume successfully

Regards,

ionblue · Mar 9, 2014

Need more help...

I thought I had at least the rules setup to have 2 ports bypass the VPN for one source IP, but that doesn't seem to be the case. I can't seem to get Plex/Web connecting on the port specified and I'm kind of perplexed. I've tried all kinds of combinations or forwarding, nat, prerouting.... nothing seems to be allowing the connection which leads me to believe that it's traversing the VPN which won't allow an incoming connection on a specific port.

Can someone have a look at what I've got and tell me what I need to do to get that portion working?

The below is supposed to take all traffic from the source IP and route to the VPN. Then it's supposed allow ports 563 (news) and 32400 (Plex/Web) to bypass the VPN. News works, but I think that works because it isn't an incoming port. I believe Plex needs an incoming port opened/forwarded?

I did find another on this thread that had a setup for Plex and tried that prerouting line, but it didn't work either. The only thing that works is not routing over the VPN.

Thanks in advance... again...

---
#!/bin/sh
#
# SHELL COMMANDS FOR MAINTENANCE.
# DO NOT UNCOMMENT, THESE ARE INTENDED TO BE USED IN A SHELL COMMAND LINE
#
# List Contents by line number
# iptables -L PREROUTING -t mangle -n --line-numbers
# iptables -t mangle -L -nv --line
#
# Delete rules from mangle by line number
# iptables -D PREROUTING type-line-number-here -t mangle
#
# To list the current rules on the router, issue the command:
# iptables -t mangle -L PREROUTING
#
# Flush/reset all the rules to default by issuing the command:
# iptables -t mangle -F PREROUTING
#
# iptables -L -n -v

ip route flush table 10
ip route del default table 10
ip rule del fwmark 10 table 10
ip route flush table 12
ip route del default table 12
ip rule del fwmark 12 table 12
ip route flush cache
iptables -t mangle -F PREROUTING

tun_if="tun11"
tun_ip=$(ifconfig $tun_if | grep 'inet addr:'| cut -d: -f2 | awk '{ print $1}')

ip route add default via $tun_ip dev $tun_if table 10
ip rule add fwmark 10 table 10
ip route add default via $(nvram get wan0_gateway) dev eth0 table 12
ip rule add fwmark 12 table 12

echo 0 > /proc/sys/net/ipv4/conf/$tun_if/rp_filter

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 563 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 32400 -j MARK --set-mark 12

logger -t "($(basename $0))" $$ Setting up routes for VPN connection......

exit
---

ozgreg · Mar 10, 2014

If you stop your VPN connection and PLEX reports a connection then the issue with PLEX is a routing problem via your VPN otherwise you got a bigger issue than IP Routing

By default PLEX wants to route incoming connections back via the VPN endpoint which is not going to work.. Instead in your VPN configuration define two static routes from PLEX back to your router WAN IP (x.x.x.x)

route 184.169.0.0 255.255.0.0 x.x.x.x
route 54.241.12.23 255.255.255.255 x.x.x.x

ionblue · Mar 10, 2014

ozgreg said:
If you stop your VPN connection and PLEX reports a connection then the issue with PLEX is a routing problem via your VPN otherwise you got a bigger issue than IP Routing

By default PLEX wants to route incoming connections back via the VPN endpoint which is not going to work.. Instead in your VPN configuration define two static routes from PLEX back to your router WAN IP (x.x.x.x)

route 184.169.0.0 255.255.0.0 x.x.x.x
route 54.241.12.23 255.255.255.255 x.x.x.x

I tried adding these 2 routes to the wan IP and it still didn't allow Plex to connect. I even tried just routing these addresses to the eth0 device and that didn't work either. Not sure what else to try on this...

ionblue · Mar 10, 2014

Martineau said:
Tagging a device for the VPN and forcing it to ONLY use the WAN works for me using this sequence in the VPN_Select.sh script.
(P.S I am not concerned about accessing the WAN prior to the VPN becoming available!)

Code:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10 iptables -I FORWARD -i br0 -s 192.168.1.100 -o eth0 -j DROP

If I start the command on 192.168.1.100

Code:

ping -t www.ibm.com

it will continue to successfully ping via the VPN (response time is between 600ms-900ms rather than 25ms via WAN)

Checking the selective routing metrics

Code:

iptables -t mangle -nvL --line

should confirm that the PKT count for the selected device goes UP proving it is using the VPN

Code:

Chain PREROUTING (policy ACCEPT 4108K packets, 400M bytes) num pkts bytes target prot opt in out source destination nn 2412 146K MARK all -- br0 * 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.1.100-192.168.1.100 MARK set 0xA

If I then stop the VPN then the ping command should stop....

Checking the WAN blocking metrics

Code:

iptables -nvL --line

should show that the PKT count for the selected device goes UP proving it is BLOCKED from using the WAN

Code:

Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination nn 64 164K DROP all -- br0 eth0 192.168.1.100 0.0.0.0/0

subsequently simply deleting the WAN BLOCKING rule

Code:

iptable -D FORWARD nn

then allows 192.168.1.100 to browse via the WAN as normal.

In the case of routing everything apart from a couple of ports 563 and 32400 then if we assume by default all traffic bypasses the VPN, in theory the following command (and only requires table 10) should suffice:

i.e. Use VPN for source 192.168.1.100 if port <> 563 and port <> 32400

Code:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -m multiport -p tcp --dport ! 563,32400 -j MARK --set-mark 10

would be the only selective routing command required - but I don't think the ! syntax works for -m multiport :-(

So 3 explicit commands are probably required as U have specified to use both table 10 and table 12.

NOTE: Rule order in iptable Chains is fraught with pitfalls, and is often the cause when an expected rule is prempted :-(

Code:

iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 32400 -j MARK --set-mark 12 iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -p tcp --dport 563 -j MARK --set-mark 12 iptables -t mangle -A PREROUTING -i br0 -s 192.168.1.100 -j MARK --set-mark 10

and we can probably be more explicit with the blocking rules (order critical!)

i.e. in firewall-start/nat-start

Code:

iptables -I FORWARD -i br0 -s 192.168.1.100 -o eth0 -j DROP iptables -I FORWARD -i br0 -s 192.168.1.100 -p tcp --dport 563 -o eth0 -j ACCEPT iptables -I FORWARD -i br0 -s 192.168.1.100 -p tcp --dport 32400 -o eth0 -j ACCEPT

Hopefully you can test out if the above works and should be able to see if/when any of the blocking rules are firing.

Also check for iptable duplicates, as firewall-start/nat-start can fire for multiple events/interfaces :-(

So best to have a reboot of the router then manually test the above.

i.e.

Code:

1. Turn off 192.168.1.00 2. Enter the 3 blocking rules 3. Turn on 192.168.1.100 Confirm that 192.168.1.100 can ONLY access port 563 or 32400 via the WAN Start the following (hopfully it should timeout) ping -t www.ibm.com 4. Start VPN 5. Enter the three MARK commands (if they are not already in the VPN_Select.sh script) 6. Confirm that 192.168.1.100 is using the VPN for all traffic except ports 563 and 32400 The ping command should now show success. 7. Stop VPN Confirm that 192.168.1.100 can only access port 563 or 32400 via the WAN The ping command should show timeout 8. Start VPN The ping command should resume successfully

Regards,

Thanks for all this. I've tried everything and the only thing I can get to work is forwarding traffic on port 563 over the WAN and everything else from that IP on the VPN. I can't get Plex to accept incoming connections at all.

Also for Plex, it's mapping an external port of 10563 to an internal port of 32400. I tried putting both those in and still couldn't get it to work. The only that works is when I remove the main command to send traffic to the VPN.

This is all getting mapped via UPNP just so you know.

I even tried adding some static routes as another person suggested and even that didn't work.

Do I need to forward those ports to the eth0 interface instead of prerouting?

Martineau · Mar 10, 2014

ionblue said:
Thanks for all this. I've tried everything and the only thing I can get to work is forwarding traffic on port 563 over the WAN and everything else from that IP on the VPN. I can't get Plex to accept incoming connections at all.

Also for Plex, it's mapping an external port of 10563 to an internal port of 32400. I tried putting both those in and still couldn't get it to work. The only that works is when I remove the main command to send traffic to the VPN.

This is all getting mapped via UPNP just so you know.

I even tried adding some static routes as another person suggested and even that didn't work.

Do I need to forward those ports to the eth0 interface instead of prerouting?

I now understand that this is peculiar to the PLEX app
(which I don't use) so if I have interpreted the solution correctly you simply need to perform two actions:

1. Add your custom external port mapping to the WAN-Virtual Server / Port Forwarding tab to forward it to port 32400 on your server

2. Add the two route statements to the OpenVPN client custom configuration panel.

Hopefully item 1. will be confirmed if U dump the iptables, and the routes in item 2. should also be shown in Syslog, when the OpenVPN client connects.

Regards,

ionblue · Mar 10, 2014

Martineau said:
I now understand that this is peculiar to the PLEX app
(which I don't use) so if I have interpreted the solution correctly you simply need to perform two actions:

1. Add your custom external port mapping to the WAN-Virtual Server / Port Forwarding tab to forward it to port 32400 on your server

2. Add the two route statements to the OpenVPN client custom configuration panel.

Hopefully item 1. will be confirmed if U dump the iptables, and the routes in item 2. should also be shown in Syslog, when the OpenVPN client connects.

Regards,

OK. I understand how to add the port mapping, but want to be sure of what I'm doing for the routes. When I was trying them I was adding them on the command line like this:

route add -net 184.169.0.0 netmask 255.255.0.0 dev eth0
route add -net 54.241.12.23 netmask 255.255.255.255 dev eth0

I also tried this:

route add -net 184.169.0.0 netmask 255.255.0.0 gw 72.185.x.x
route add -net 54.241.12.23 netmask 255.255.255.255 gw 72.185.x.x

Obviously doing it with the device is certainly easier than using the IP of the interface since that can change. However, if I can add these to the end of my vpn_route_up.sh file that gets called when the VPN starts up, I can set a variable to get the interface IP and pass that to the route commands.

But… are you telling me that this is NOT the proper place to add the routes? Do I need to add them straight into the OpenVPN custom configuration window?

And thanks again for all your help thus far. You've certainly stuck with me while trying to figure this all out!

ionblue · Mar 10, 2014

And I was wrong. That other port is only used if you don't manually choose a port in the Plex preferences. So I put a forward in from 32400 to 32400 instead, but even after adding the routes as I stated, it still doesn't connect. Frustrating.

ionblue · Mar 10, 2014

Also I just verified that my port mapping does indeed work when I pull out the prerouting statements and Plex connects. As soon as I add them back, no matter the order, it doesn't work. So the routes are probably what is needed, but again, those didn't work the way I was adding them.

ionblue · Mar 10, 2014

I've been digging around on the Plex forums as well and came across a thread that tackles this, but I have no idea what this guy is doing when he's adding routes. Apparently the Plex.tv IP's tend to change quite a bit so he wrote a script that he runs every hour through cron on his router to update things automatically. Problem is, I don't know how to incorporate this type of thing with Asuswrt-Merlin.

Don't know if I need to go this far, but do you think any of this will work with my setup?

This is the other guys setup. His Plex server IP is 192.168.1.7.

---
In Firewall:

iptables -N myplex
#Jump to myplex chain to check if connecting to myplex
iptables -I FORWARD -s 192.168.1.7 -j myplex

In WAN UP

iptables -t mangle -N MYPLEX
#Jump to MYPLEX chain
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.1.7 -j MYPLEX
#Run script
/opt/myplex/plexdns.sh

Script: (In my case named 'plexdns.sh')

#!/bin/sh

#Flush chains
iptables -t mangle -F MYPLEX
iptables -F myplex

DNS="$(dig plex.tv +short) $(dig @8.8.8.8 plex.tv +short) $(dig @209.244.0.3 plex.tv +short)"
UNIQ_IP=$(echo "$DNS" | tr ' ' '\n' | sort -u | tr '\n' ' ')

for IP in $UNIQ_IP
do
iptables -t mangle -A MYPLEX -d "$IP" -j MARK --set-mark 1
iptables -I myplex -d "$IP" -j ACCEPT
done
---

I dunno. I'm about to completely give up on this at this point. I'm kind of at my wits end trying to get this portion to work.

ionblue · Mar 10, 2014

I posted on the other forum and the guy stated he used the info on the following post to get his working with Tomato Shibby and I believe this is the same thing that was posted at the beginning of this thread:

http://www.linksysinfo.org/index.ph...-ports-through-vpn-openvpn.37240/#post-205781

So he's doing that, port forwarding, sending port 32400 traffic over the non-vpn, and setting routes. So I must be close to getting this working, but just can't get routes to do anything at all. Which means I'm probably not adding them properly.

Martineau · Mar 10, 2014

ionblue said:
I posted on the other forum and the guy stated he used the info on the following post to get his working with Tomato Shibby and I believe this is the same thing that was posted at the beginning of this thread:

http://www.linksysinfo.org/index.ph...-ports-through-vpn-openvpn.37240/#post-205781

So he's doing that, port forwarding, sending port 32400 traffic over the non-vpn, and setting routes. So I must be close to getting this working, but just can't get routes to do anything at all. Which means I'm probably not adding them properly.

I assume the following commands are what is suggested that need to be included as part of the VPN_Select.sh script:

Code:

ip route add 184.169.0.0/16 via $(nvram get wan0_gateway)
ip route add 54.241.12.23/32 via $(nvram get wan0_gateway)

and the output of the route display command should show if the routing table is modifed correctly.

If there are indeed different PLEX addresses then these can also be added manually until a working configuration is achieved before modifying the scripts.

As stated before, starting from a clean base will be easier, so best to start the manual routing manipulation after a reboot.

Regards,

Skirk · Mar 23, 2014

It's all working, but....

So, I followed the excellent instructions and I have selective OpenVPN working like a charm.

However, on starting the client I get these errors:

Code:

Mar 23 17:08:49 openvpn[9887]: [server] Peer Connection Initiated with [AF_INET]198.23.71.91:1194
Mar 23 17:08:51 openvpn[9887]: Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: TUN/TAP device tun11 opened
Mar 23 17:08:51 openvpn[9887]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mar 23 17:08:51 openvpn[9887]: /usr/sbin/ip link set dev tun11 up mtu 1500

I know it probably doesn't matter but error codes bug me as I'm a noob and don't know when I should ignore them or not

Thanks

Martineau · Mar 23, 2014

Skirk said:

So, I followed the excellent instructions and I have selective OpenVPN working like a charm.

However, on starting the client I get these errors:

Code:

Mar 23 17:08:49 openvpn[9887]: [server] Peer Connection Initiated with [AF_INET]198.23.71.91:1194
Mar 23 17:08:51 openvpn[9887]: Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
Mar 23 17:08:51 openvpn[9887]: TUN/TAP device tun11 opened
Mar 23 17:08:51 openvpn[9887]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mar 23 17:08:51 openvpn[9887]: /usr/sbin/ip link set dev tun11 up mtu 1500

I know it probably doesn't matter but error codes bug me as I'm a noob and don't know when I should ignore them or not

Thanks

By default, a VPN client usually accepts the VPN server-side configuration without question.

With 'selective routing' we have stated 'route-nopull' which is a request to reject the server supplied directives (in this case routing info) as apparently we think we know best and seemingly know what we are doing!

So the client VPN messages are simply a documented disclaimer/reminder should things not go as expected!

Regards,

Skirk · Mar 23, 2014

Thanks Martineau, that makes sense.

This setup is just so sweet now. No need for a proprietary client for selective routing or a second router & subnet for the VPN. Thanks all

Thread starter	Title	Forum	Replies	Date
E	Multi source selective port forward?	Asuswrt-Merlin	1	Dec 28, 2023
C	Routing my VPN Server through VPN Client 1 Having issues with Facetime	Asuswrt-Merlin	50	Jul 30, 2024
O	PI hole + unbound + domain vpn routing	Asuswrt-Merlin	10	Jun 26, 2024
	VPN Stays connected but Stops Routing after DoH Change	Asuswrt-Merlin	2	Jun 25, 2024
T	[Solved]Configure Policy based routing for transparent proxy	Asuswrt-Merlin	6	Jun 13, 2024
M	OpenVPN / site to site with special security/routing constraints	Asuswrt-Merlin	7	Apr 8, 2024
	Bug Report: nvram chilli_enable=1 when guest network is removed causes no routing to occur	Asuswrt-Merlin	2	Jan 9, 2024
G	[Help] Routing VPN server through VPN client (external VPN Provider)	Asuswrt-Merlin	14	Dec 27, 2023
P	IPv6 routing table flags	Asuswrt-Merlin	2	Dec 21, 2023
	Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices	Asuswrt-Merlin	26	Sunday at 11:56 AM

Selective Routing with Asuswrt-Merlin

Occasional Visitor

Part of the Furniture

Occasional Visitor

Occasional Visitor

Occasional Visitor

Part of the Furniture

Occasional Visitor

New Around Here

Occasional Visitor

Occasional Visitor

Part of the Furniture

Occasional Visitor

Occasional Visitor

Occasional Visitor

Occasional Visitor

Occasional Visitor

Part of the Furniture

Occasional Visitor

Part of the Furniture

Occasional Visitor

Similar threads

Similar threads

Support SNBForums w/ Amazon

Sign Up For SNBForums Daily Digest