Kill Switch, Exclusive DNS not working with 2 VPN

[CODYQX4]

I've been unable to get policy routing working properly with two VPNs, with either the stable build or alpha 3.

Without any scripts (I removed them to debug the issue and rule out the scripts), the DNS doesn't get forced without DNSFilter (even on alpha 3 it will use OpenDNS). Also, if I stop the VPN, the clients just use the WAN even though I set the drop clients when tunnel down option.

I also seem to get IP/Route conflict warnings, although both VPNs are active and routing the clients as defined (but no working kill switch).

 

[Martineau]

I've been unable to get policy routing working properly with two VPNs, with either the stable build or alpha 3.

Without any scripts (I removed them to debug the issue and rule out the scripts), the DNS doesn't get forced without DNSFilter (even on alpha 3 it will use OpenDNS). Also, if I stop the VPN, the clients just use the WAN even though I set the drop clients when tunnel down option.

I also seem to get IP/Route conflict warnings, although both VPNs are active and routing the clients as defined (but no working kill switch).

Unless you need to enable Selective Port Routing, then scripts should not be necessary for most users.

It appears that if the VPN disconnects from the server end, then the 'blocking' entries should be inserted into the appropriate RPDB tables, however, when stopping the VPNs manually via the GUI there doesn't always seem to be an appropriate event triggered to /usr/sbin/vpnrouting.sh

I uses a script to manage the VPN state...useful for scheduling VPN access via cron etc. and this also addresses the 'Error Routing conflict' see:

http://www.snbforums.com/threads/op...service-state-apply-button.30410/#post-237935

 

[CODYQX4]

I do actually need Selective Port routing, but I started from scratch to rule out issues.

The exclusive DNS is not working for me, both VPNs use the router DNS even on exclusive DNS.

I was using DNSFilter to fix that, but Alpha 3 claims that is no longer needed.

It's good to know the routing error is just a cosmetic bug, because despite seeing it, traffic was working in all cases.

Could you show me some examples on how/where you make use of that script?

 

[Martineau]

I do actually need Selective Port routing, but I started from scratch to rule out issues.
<snip>

Could you show me some examples on how/where you make use of that script?

The VPN_Client_Switch.sh script can obviously be used in wan-start to emulate the setting of the 'start-with-WAN' GUI radio button, although at boot time, hopefully there are no conflicting VPN routes defined!

Using cron I can schedule a VPN switch to say either West Coast/East Coast USA nodes provided by my VPN ISP.

However I have the call to my script in nat-start, as I have ARM routers which are susceptible to the Trend Micro engine arbitrarily flushing any Selective Port Routing fwmark tagging

# Is the actual VPN client UP....well is there a route to the VPN? or does folder /etc/openvpn/clientx exist?
# If so then selective routing tagging will be broken until the '-t mangle PREROUTING' chain is reinstated for the VPN Client
VPN_LIST="1 2"
for VPNID in $VPN_LIST
   do
       VPNROUTE=`ip route show | grep -i -a "dev tun1"$VPNID`
       logger -s -t "($(basename $0))" $$ "Checking if VPN Client$VPNID is UP...."$VPNROUTE
       if [ "$VPNROUTE" != "" ];then
          logger -s -t "($(basename $0))" $$ "**Warning VPN Client$VPNID is UP.... restarting VPN Client$VPNID"
          #service restart_vpnclient$VPNID
          /jffs/scripts/VPN_Client_Switch.sh $VPNID "on"
          sleep 30        # Delay starting the second VPN client just to keep the syslog entries separate for easier debugging
       fi
   done

As you can see, the original snippet of code above simply called 'service restart_vpnclient$VPNID' but I needed to ensure that the script is capable of identifying the current ACTIVE VPN Client(s) by ensuring that a stop of any ACTIVE VPN Client flushes the routes.

 

[CODYQX4]

The VPN_Client_Switch.sh script can obviously be used in wan-start to emulate the setting of the 'start-with-WAN' GUI radio button, although at boot time, hopefully there are no conflicting VPN routes defined!

Using cron I can schedule a VPN switch to say either West Coast/East Coast USA nodes provided by my VPN ISP.

However I have the call to my script in nat-start, as I have ARM routers which are susceptible to the Trend Micro engine arbitrarily flushing any Selective Port Routing fwmark tagging

# Is the actual VPN client UP....well is there a route to the VPN? or does folder /etc/openvpn/clientx exist?
# If so then selective routing tagging will be broken until the '-t mangle PREROUTING' chain is reinstated for the VPN Client
VPN_LIST="1 2"
for VPNID in $VPN_LIST
   do
       VPNROUTE=`ip route show | grep -i -a "dev tun1"$VPNID`
       logger -s -t "($(basename $0))" $$ "Checking if VPN Client$VPNID is UP...."$VPNROUTE
       if [ "$VPNROUTE" != "" ];then
          logger -s -t "($(basename $0))" $$ "**Warning VPN Client$VPNID is UP.... restarting VPN Client$VPNID"
          #service restart_vpnclient$VPNID
          /jffs/scripts/VPN_Client_Switch.sh $VPNID "on"
          sleep 30        # Delay starting the second VPN client just to keep the syslog entries separate for easier debugging
       fi
   done

As you can see, the original snippet of code above simply called 'service restart_vpnclient$VPNID' but I needed to ensure that the script is capable of identifying the current ACTIVE VPN Client(s) by ensuring that a stop of any ACTIVE VPN Client flushes the routes.

What does your openvpn-event look like? The ones I see always copy from tun11 but I didn't know if it needed additional tun1X in that case.