ssh and openvpn, is it operator error? RESOLVED

[Cake]

Could someone test this out on their system.

Final edit: Simplified my post

SSH from device behind router's openvpn connection to a public ip. Type ss -tp.

ISP IP is showing and not VPN's IP.
AC68U 380.57

 

[Cake]

Today I did a factory default/reset and tried to repeat the above issue.

After I reset rmerlin 380.57 (AC68U), I went straight to configuring VPN clients, no other tasks.

Background:
I recently changed my router from rebooting nightly to once a week, that is part of my problem. I should go back to nightly.
Its also operator error as well.

To replicate the above post you need:
-Two VPN clients running on router,
-A vps or another linux box to ssh too outside of your wan.

When setting up vpn client policy, make a conflict between 2 devices. Example 1 device on your network is being handled by both vpn1 client and vpn2 client (both in the routers gui).
Then test my first post. Your web browser will tell you that your ip is the vpn ip while ssh will tell you that you are connected from your isp ip.
I checked my screenshots of my routers gui before I factory reset, and went back, and found no conflicts there. I think I must have been changing settings a while back on lets say vpnclient1, and there was a conflict briefly while I hit apply, and went to the other vpn client to add/remove conflict. Thats all it takes and, the trouble will stay until router is rebooted.
I hope my above ramblings can be understood. I don't expect a fix, but just a heads up if you use more then 1 vpn client, you might want to verify no conflicts, and reboot after changing settings.

 

[Cake]

I just set up vpn1 client and vpn2 client, both using policy, and no conflicts between the two. Again as first post, however after a reboot, ssh goes through the vpn as expected.
This is on 380.57.2_HGG-FINAL (AC68U)
Bottom line is - reboot after making changes if using multiple vpn clients.

 

[Martineau]

I just set up vpn1 client and vpn2 client, both using policy, and no conflicts between the two. Again as first post, however after a reboot, ssh goes through the vpn as expected.
This is on 380.57.2_HGG-FINAL (AC68U)
Bottom line is - reboot after making changes if using multiple vpn clients.

Indeed, a reboot is always prudent after playing/experimenting with any GUI settings!

However, whilst I did get confused by your post, I thought I should try to emulate your 'bug' report.

Add 172.0.0.98 to VPN Client 1 - but say I made a typo and incorrectly entered 172.0.0.99

(vpnrouting.sh): 5255 Patched by John9527/Martineau vpnrouting.sh
openvpn-routing: Configuring policy rules for client 1 to 113.29.228.130
openvpn-routing: Creating VPN routing table
openvpn-routing: Removing routes 0.0.0.0/1,128.0.0.0/1 from table main
openvpn-routing: Removing rule 1101 from routing policy
openvpn-routing: Added 172.0.0.1 to 0.0.0.0 through VPN to routing policy
openvpn-routing: Added 172.0.0.99 to 0.0.0.0 through VPN to routing policy
openvpn-routing: Setting default route 10.200.5.11 for table 111
openvpn-routing: Setting VPN Server 1 route 10.8.0.0/24 for table 111
openvpn-routing: Setting VPN Client bridge route 10.3.0/24 for table 111
openvpn-routing: Completed routing policy configuration


ip rule

0:  from all lookup local
900:    from 10.3.0.0/24 lookup hma
1101:   from 172.0.0.1 lookup hma
1102:   from 172.0.0.99 lookup hma
1301:   from 172.0.0.2 lookup vpn2
32766:  from all lookup main
32767:  from all lookup default

Now I add 172.0.99 routed via VPN Client 2 but this now inadvertently becomes broken by the previous mistake resulting in conflicting RPDBP routing...

(vpnrouting.sh): 5616 Patched by John9527/Martineau vpnrouting.sh
openvpn-routing: Configuring policy rules for client 2 to 192.157.56.146
openvpn-routing: Creating VPN routing table
openvpn-routing: Removing routes 0.0.0.0/1,128.0.0.0/1 from table main
openvpn-routing: Removing rule 1301 from routing policy
openvpn-routing: Added 172.0.0.2 to 0.0.0.0 through VPN to routing policy
openvpn-routing: Added 172.0.0.99 to 0.0.0.0 through VPN to routing policy
openvpn-routing: Tunnel re-established, restoring WAN access to VPN clients
openvpn-routing: Setting default route 10.200.5.77 for table 112
openvpn-routing: Setting VPN Server 1 route 10.8.0.0/24 for table 112
openvpn-routing: Setting VPN Client bridge route 10.3.0/24 for table 112
openvpn-routing: Completed routing policy configuration

ip rule

0:  from all lookup local
900:    from 10.3.0.0/24 lookup hma
1101:   from 172.0.0.1 lookup hma
1102:   from 172.0.0.99 lookup hma
1301:   from 172.0.0.2 lookup vpn2
1302:   from 172.0.0.99 lookup vpn2
32766:  from all lookup main
32767:  from all lookup default

So at this point ALL traffic (including SSH) outbound from 172.0.99 will go via the incorrect route.
But are you saying that for you, SSH (despite going through a VPN Client tunnel) still reports your ISP WAN address rather than the VPN Address?

Eventually I realise my mistake and remove the routing conflict from VPN Client 1, consequently the vpnrouting.sh script corrects the RPDB table:

(vpnrouting.sh): 5943 Patched by John9527/Martineau vpnrouting.sh
openvpn-routing: Configuring policy rules for client 1 to 113.29.228.130
openvpn-routing: Creating VPN routing table
openvpn-routing: Removing routes 0.0.0.0/1,128.0.0.0/1 from table main
openvpn-routing: Removing rule 1101 from routing policy
openvpn-routing: Removing rule 1102 from routing policy
openvpn-routing: Added 172.0.0.1 to 0.0.0.0 through VPN to routing policy
openvpn-routing: Setting default route 10.200.5.11 for table 111
openvpn-routing: Setting VPN Server 1 route 10.8.0.0/24 for table 111
openvpn-routing: Setting VPN Client bridge route 10.3.0/24 for table 111
openvpn-routing: Completed routing policy configuration

ip rule

0:  from all lookup local
900:    from 10.3.0.0/24 lookup hma
1101:   from 172.0.0.1 lookup hma
1301:   from 172.0.0.2 lookup vpn2
1302:   from 172.0.0.99 lookup vpn2
32766:  from all lookup main
32767:  from all lookup default

NOTE: RPDB Selective routing is applied in numerically ascending order WAN,VPN1,VPN2,... etc.

The only problem I can see is that if you didn't remember to hit APPLY in the GUI when removing a selective route then a reboot will still leave the RPDB table 'broken'.

So I can't seem to be able to replicate your issue, but as you say, when in doubt reboot!

 

[Cake]

Thanx Martineau for trying it out. So yes after I change a policy setting, hit apply with one of the two vpn clients running, ssh no longer goes through vpn, (as well as minecraft game). There is no conflict in policy.

You can see when you log into a machine outside your wan, by typing ss -tp.

So lets say my desktop is running behind my router. I have two vpn clients running using policy on router's gui. I set up vpn1 client to route my desktop to vpn1, I set vpn2 client policy on router to route a raspi to a different vpn (vpn2). Everything works fine at this point. I decide I want to add another device behind my lan to go through vpn1 or vpn2. I make changes in gui, no conflicts, hit apply and wait, but not reboot. Next I open terminal on Desktop and type ssh name@host (a vps outside my lan). After I log in I type ss -tp and it shows my routers edge ISP IP. To fix- I reboot the router. After reboot everything is good again.

I appreciate your time checking to see if you can replicate.

Edit: I just retested the bug out again, just like above I made a change to vpnclient1, (add another device to the policy) hit apply, (Desktop and another device now going through vpnclient1) opened terminal and SSH no longer goes through vpnclient1. I can make changes to vpnclient2 without it affecting devices on vpnclient1 it seems.

 

[Martineau]

Thanx Martineau for trying it out. So yes after I change a policy setting, hit apply with one of the two vpn clients running, ssh no longer goes through vpn, (as well as minecraft game). There is no conflict in policy.

You can see when you log into a machine outside your wan, by typing ss -tp.

So lets say my desktop is running behind my router. I have two vpn clients running using policy on router's gui. I set up vpn1 client to route my desktop to vpn1, I set vpn2 client policy on router to route a raspi to a different vpn (vpn2). Everything works fine at this point. I decide I want to add another device behind my lan to go through vpn1 or vpn2. I make changes in gui, no conflicts, hit apply and wait, but not reboot. Next I open terminal on Desktop and type ssh name@host (a vps outside my lan). After I log in I type ss -tp and it shows my routers edge ISP IP. To fix- I reboot the router. After reboot everything is good again.

I appreciate your time checking to see if you can replicate.

Edit: I just retested the bug out again, just like above I made a change to vpnclient1, (add another device to the policy) hit apply, (Desktop and another device now going through vpnclient1) opened terminal and SSH no longer goes through vpnclient1. I can make changes to vpnclient2 without it affecting devices on vpnclient1 it seems.

You will need to compare before and after

ip route
ip route show table 111
ip route show table 112

when you

add another device behind my lan to go through vpn1 or vpn2.

Because I have patched vpnrouting.sh (it is broken when using multiple concurrent VPN clients via the same VPN ISP) my custom RPDB tables 111 and 112 each contain only 1 entry

ip   route   show   table   111

default via 10.200.5.77 dev tun11

and

ip   route   show   table   112

default via 10.200.5.77 dev tun12

created from

ip   route

<snip>
10.200.4.0/22 dev tun11  proto kernel  scope link  src 10.200.5.11
10.200.4.0/22 dev tun12  proto kernel  scope link  src 10.200.5.77
<snip>

So in my configuration, there are no references in table 111 to tun12 and no references in table 112 to tun11.

NOTE: The crucial thing is that the defaults are unique to each table and there is no 0.0.0.0/1 entry in any of the tables 254,111,112.

P.S. This config may not work for AirVPN VPN Clients as I believe AirVPN allows inbound connections through the VPN tunnel, and requires multiple entries in tables 111 and 112.

 

[Cake]

I was going to make a log and post here, but guess what...I had trouble replicating the problem.
I tried two static ip commercial vpns, then the same with domain names, everything worked liked it should.

When I put my setup back in I get the trouble again-
vpn1client -commercial vpn (PIA)
vpn2client-Private vpn (openvpnas) running on a vps (the same one I log into via SSH from device connected to vpnclient1 (connected to PIA)

I know you probably went cross eyed from reading the above. hehe
Its all good, I will just remember to reboot after making changes.
cheers

 

[Cake]

My problem is now RESOLVED.
Thank you John and Martineau.
My problem was the same as Martineau's listed here.
I am using Martineau's patched version of John's vpnrouting.sh script for both vpn clients.
I run Martineau's FixRPDBVPN.sh script after making any changes to vpn GUI. (add--> fi <--to end of script if its missing),.

More background on original problem:
What I found weird is every "whats my ip" web site from my browser (cleared cache) will show my vpn ip, but in fact according to apache logs, sshd, imap on a vps all showing my ISP IP.
If your using 2 vpn clients, and policy, you may want to check if its working other then by the curl/wget method, or going to a web site "whats my ip..."

Big Thanks!