VPN Director Assistance Request

[js28194]

Hello, hoping someone can push in the right direction. I have VPN director setup specifically 2 IP's I route outside to WAN and all rest to VPN. Problem that one of the works, 241 routes outside of VPN and the other .242 does not and routes internally through VPN instead. I have diversion installed if that means anything. I test by performing a tracert on both machines to 8.8.8.8 and again .241 routes outside of WAN and .242 routes inside through VPN. Any thoughts on what I can look into?

 

[js28194]

All other devices also go through VPN as desired, so only issue is SERVER2 .241 address going through VPN though it should go through WAN.

 

[eibgrad]

Doesn't seem possible. More likely you're somehow misinterpreting the results.

Dump the internals and let's see if anything is amiss.

ifconfig
brctl show
ip route
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
ip rule
iptables -vnL
iptables -t nat -vnL

P.S. No need for separate files, one big one is enough.

 

[eibgrad]

BTW, as an aside, with all the OpenVPN clients configured w/ a kill switch, and all of them routing the *same* local IP network, it makes no sense to have them all active at the same time. The only one that will be actively routed through is OpenVPN client #1. And should its tunnel fail, the kill switch will prevent all further internet access until the tunnel for OpenVPN client #1 is reestablished (i.e., no fall-through is possible, if that was your intent).

P.S. Just noticed, only OpenVPN client #1 is actually active, so that's fine. For some reason I missed that.

 

[js28194]

Thank you for that. I only have one VPN client enabled at a time. I have attempted to mask some personal ip addresses and port #'s from this file. There are just straight replacements with different numbers equally across everything. I also have a VPN Server running on a port (TAP) which works fine and a couple of port forwards.

 

[eibgrad]

Well that didn't take long. Something else is marking packets and routing through the OpenVPN client(s) and main routing table, and it has higher priority than the VPN Director.

admin@GT-AX11000-25C0:/tmp/home/root# ip rule
0:      from all lookup local
150:    from all fwmark 0x8000/0xf000 lookup main
1000:   from all fwmark 0x1000/0xf000 lookup ovpnc1
2000:   from all fwmark 0x2000/0xf000 lookup ovpnc2
4000:   from all fwmark 0x7000/0xf000 lookup ovpnc4
10010:  from 192.168.70.241 lookup main
10011:  from 192.168.70.242 lookup main
10210:  from 192.168.70.0/24 lookup ovpnc1
10610:  from 192.168.70.0/24 lookup ovpnc3
10810:  from 192.168.70.0/24 lookup ovpnc4
11010:  from 192.168.70.0/24 lookup ovpnc5
32766:  from all lookup main
32767:  from all lookup default

 

[js28194]

Maybe I reboot the router.

 

[js28194]

Well that didn't take long. Something else is marking packets and routing through the OpenVPN client(s) and main routing table, and it has higher priority than the VPN Director.

admin@GT-AX11000-25C0:/tmp/home/root# ip rule
0:      from all lookup local
150:    from all fwmark 0x8000/0xf000 lookup main
1000:   from all fwmark 0x1000/0xf000 lookup ovpnc1
2000:   from all fwmark 0x2000/0xf000 lookup ovpnc2
4000:   from all fwmark 0x7000/0xf000 lookup ovpnc4
10010:  from 192.168.70.241 lookup main
10011:  from 192.168.70.242 lookup main
10210:  from 192.168.70.0/24 lookup ovpnc1
10610:  from 192.168.70.0/24 lookup ovpnc3
10810:  from 192.168.70.0/24 lookup ovpnc4
11010:  from 192.168.70.0/24 lookup ovpnc5
32766:  from all lookup main
32767:  from all lookup default

To confirm then, I am not an idiot? I know how to read a tracert, and looking at the GUI, my config should be straight forward correct?

 

[eibgrad]

To confirm then, I am not an idiot? I know how to read a tracert, and looking at the GUI, my config should be straight forward correct?

LOL. That's why I had you dump the internals. There's always a risk from a conflict. I have no clue about the source. If the problem persists after a reboot, perhaps a dump of the mangle table might prove useful as well.

iptables -t mangle -vnL

 

[eibgrad]

I did a search on "0x8000/0xf000" and got a hit on the following link.

Domain-based VPN Routing Script

Domain VPN Routing is a tool used to route specific website domains to specific VPN tunnels or override all traffic being routed to a VPN tunnel to directly route through a WAN interface. ***v2.1.0 Release**** This is the release information regarding v2.1.0, please read the notes carefully...

www.snbforums.com

Any chance you're using the above script? Or just forgot you installed it?

 

[js28194]

Sadly reboot did not fix it.

 

[js28194]

I did a search on "0x8000/0xf000" and got a hit on the following link.

Domain-based VPN Routing Script

Domain VPN Routing is a tool used to route specific website domains to specific VPN tunnels or override all traffic being routed to a VPN tunnel to directly route through a WAN interface. ***v2.1.0 Release**** This is the release information regarding v2.1.0, please read the notes carefully...

www.snbforums.com

Any chance you're using the above script? Or just forgot you installed it?

Yes, I do have that script but it is very limited to domain names. Have some domains mandating outside of VPN regardless of what machines internally and then I have a few mandated by (241 & 242) to route over VPN and that has been working fine for a very long time. This is new after I did a speed test today.

I only have two polices, Inside & Outside. Some kind fella in that thread gave me some addtions to the openvpn-event script to "automagically" change the interface when click off on client1 and click connect on client2. It changes that with the proper OPVN_ID I think.

#!/bin/sh

confpath="/jffs/configs/domain_vpn_routing/domain_vpn_routing.conf"

[ "${dev:0:4}" = 'tun1' ] && vpn_id=${dev:4:1} && [ "$script_type" = 'route-up' ] && sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath" &

#PoC
#vpn_id=2
#sed -i "s/ovpnc./ovpnc$vpn_id/" "$confpath"

sh /jffs/scripts/domain_vpn_routing.sh cron # domain_vpn_routing

sh /jffs/scripts/domain_vpn_routing.sh querypolicy all # domain_vpn_routing_queryall

 

[eibgrad]

Yes, I do have that script but it is very limited to domain names. Have some domains mandating outside of VPN regardless of what machines internally and then I have a few mandated by (241 & 242) to route over VPN and that has been working fine for a very long time. This is new after I did a speed test today.

Well I don't know anything about that script, or how you configured it. But it's extremely likely it is the source of the problem. Because if you were to delete those specific entries, I bet it would work correctly.

ip rule del fwmark 0x8000/0xf000 table main
ip rule del fwmark 0x1000/0xf000 table ovpnc1
ip rule del fwmark 0x2000/0xf000 table ovpnc2
ip rule del fwmark 0x7000/0xf000 table ovpnc4

 

[js28194]

That is unsatisfying but I understand. There is not much to configure in that script as long as stay away from advance options. It's just domains either route from WAN or another Interface.

admin@GT-AX11000-25C0:/tmp/home/root# ip rule del fwmark 0x8000/0xf000 table main
RTNETLINK answers: No such file or directory
admin@GT-AX11000-25C0:/tmp/home/root# ip rule del fwmark 0x1000/0xf000 table ovpnc1
RTNETLINK answers: No such file or directory
admin@GT-AX11000-25C0:/tmp/home/root# ip rule del fwmark 0x2000/0xf000 table ovpnc2
RTNETLINK answers: No such file or directory
admin@GT-AX11000-25C0:/tmp/home/root# ip rule del fwmark 0x7000/0xf000 table ovpnc4
RTNETLINK answers: No such file or directory
admin@GT-AX11000-25C0:/tmp/home/root#


Thanks for trying to help though, much appreciated.

 

[RMerlin]

BTW, as an aside, with all the OpenVPN clients configured w/ a kill switch, and all of them routing the *same* local IP network, it makes no sense to have them all active at the same time. The only one that will be actively routed through is OpenVPN client #1. And should its tunnel fail, the kill switch will prevent all further internet access until the tunnel for OpenVPN client #1 is reestablished (i.e., no fall-through is possible, if that was your intent).

Killswitch rules should have a lower priority (higher prio value)) than all VPN routing rules, so they should only kick in if none of the connected VPN clients was working.

        Rule priority allocations:

        VPNDIR_PRIO_ALL
        - 10000-10009: clients set to OVPN_RGW_ALL

        VPNDIR_PRIO_WAN
        - 10010-10209: WAN rules


        VPNDIR_PRIO_OPENVPN
        - 10210-10409: OVPN 1
        - 10410-10609: OVPN 2
        - 10610-10809: OVPN 3
        - 10810-11009: OVPN 4
        - 11010-11209: OVPN 5

        VPNDIR_PRIO_WIREGUARD
        - 11210-11409: WGC 1
        - 11410-11609: WGC 2
        - 11610-11809: WGC 3
        - 11810-12009: WGC 4
        - 12010-12209: WGC 5

        VPNDIR_PRIO_KS_OPENVPN
        - 12210-12214 (OVPN1 through 5, multiple rules per unit)

        VPNDIR_PRIO_KS_WIREGUARD
        - 12215-12219 (WG1 through 5, multiple rules per unit)

        VPNDIR_PRIO_KS_SDN
        - 122220

 

[eibgrad]

Yes, I do have that script but it is very limited to domain names. Have some domains mandating outside of VPN regardless of what machines internally and then I have a few mandated by (241 & 242) to route over VPN and that has been working fine for a very long time. This is new after I did a speed test today.

I assume you turned to that third-party script because the VPN Director doesn't handle domain names.

Ironically, if the route directives in custom config were handled correctly by the OpenVPN client's routing routines, you could probably avoid using a third-party script for those purposes.

OpenVPN Client: mishandled route directives

ASUS RT-AC68U - 386.14 I'm trying to help the OP w/ the following problem. https://www.snbforums.com/threads/vpn-director-question.91225/ One approach I was considering is to add route directives to the custom config field of the OpenVPN client to route the following domains through the WAN...

www.snbforums.com

 

[js28194]

Well, I hope not to get in the middle of anything, but as you may have seen, my tracert is to ip address so I am not sure the domain name script would even get involved. Ranger's script has/does serve me well and none of the domains I checked are added to his script. Example, speedtest.net is perfectly fine on .241, goes out of WAN, but inside VPN on .242 and it is not a domain that I added. tracerts are to ip address so nothing to resolve. I may have to rebuild from scratch because I know my specific configuration has worked until I did that last upgrade with 388.8 (not blaming you Merlin) and had to roll back to 338.7 and all my issues have popped up.

This is pretty simple in the past.
VPN Director
Add 5 VPN clients
Define VPN Director Rules
Launch 1 VPN Client
Test Ensure that ALL devices go through VPN
Add two WAN devices to VPN director rules
Add all others to VPN
Test two WAN devices with Traceroute ensure outside of VPN. Check.
Test two VPN devices with Traceroute ensure inside of VPN. Check.
Add Domainname routing script
Create Outside, add one domain
Create Inside, add one domain
Test Outside domain on "WAN" device and "WAN" check.
Test Inside domain on "WAN" devices (routes inside VPN) check.
Test Outside domain on "VPN" devices (routes via WAN interface) check.
Test Inside domain on "VPN" devices and obviously this works. check.

I'll have to blow it away and retry from the ground up and report back, but leaving in a few days so probably be a couple of weeks.

Again, thank you all for trying to assist. Much appreciated.