RESOLVED! - VPN Server issues (no wan access after reboot)

madme

New Around Here
I am having a weird issue openVPN, please someone help.

In short, VPN server works just after being turned on, but on reboot nothing works anymore.

These are the details:

I am trying to set up a VPN server on my RT AC3200 with merlin 384.13_8

  1. Just after I set the VPN on, everything is OK. The VPN works and I can establish a VPN connection coming from WAN. I can also surf the internet when connected to my local network.
  2. However, if I reboot the router, I loose internet access when connected from my local network (ping returns destination net unreachable), and I cannot connect to the VPN from WAN.
    I can still login to my router from LAN and I can ping with the router tools.
  3. If I disable the VPN server, internet connection still doesn´t work. I need to disable the VPN server and reboot the router to have internet connection from my local lan.
I have a double NAT. The router connected to the internet has gateway 10.0.0.111, my ASUS router has IP 10.0.0.150 / 192.168.1.1.

Attached is my booting log (slightly edited for privacy), including detailed VPN server log information. For what is worth, when pinging from my local wan, just after booting, works until approximately the following line:
Jul 20 21:59:45 rc_service: waitting "restart_diskmon" via ntpd_synced ...

After that, I receive a “Destination net unreachable” message.
 

Attachments

  • AsusBootLog.txt
    26 KB · Views: 29

eibgrad

Part of the Furniture
If your primary router has a gateway of 10.0.0.111, then remote access of the OpenVPN server isn't even possible since that IP is in the *private* IP space, and by extension, so must the WAN ip, when it needs to be in the public IP space. IOW, your primary router always needs a public IP to be remotely accessible.

When testing over the WAN, is the OpenVPN client actually on the internet side of the WAN (e.g., a smartphone using the cellular network), or are you just relying on NAT loopback (i.e., referencing the WAN ip of the primary router while still located on the LAN). Because if it's the latter, that's NOT a valid test. It could explain why you *appear* to have a working OpenVPN server when in fact you don't, NOT in the sense it's accessible over the WAN.

Also, it's going to be very difficult to diagnose ANY problems given how far behind your router's firmware is. We are well into the 386 series at this point (specifically, 386.7), and things have changed quite a bit. We didn't even have things like the VPN Director back then.
 

eibgrad

Part of the Furniture
I have a double NAT. The router connected to the internet has gateway 10.0.0.111, my ASUS router has IP 10.0.0.150 / 192.168.1.1.

Ok, after a second look, I think I see what you mean. You mean 10.0.0.111 is the gateway for the LAN side of the primary router. But hopefully the WAN ip of the primary router *is* a public IP.
 

eibgrad

Part of the Furniture
Without forcing you to upgrade the firmware, best I can suggest at this point is dumping some of the relevant data structures when things are working correctly, then when things stop working, so we can compare the differences.

Code:
ifconfig
ip route show table main
for i in 1 2 3 4 5; do echo "table ovpnc${i}"; ip route show table ovpnc${i}; done
ip rule
iptables -t nat -vnL
iptables -vnL
:

Admittedly a lot, but I don't know what I'm looking for, nor even remember if all those data structures were relevant at the time. You might be better off posting them to PasteBin (once sanitized for your public IP) rather than on the form. Or else as attachments.

Then again, maybe simply upgrading would make the problems go poof!

P.S. Given all the problems many users are having w/ wifi on 386.7 lately, might be best to go with 386.5_2 for now, again, if you choose to upgrade.
 
Last edited:

madme

New Around Here
Thank you very much for looking at my case.

I would love to upgrade version, but my router is no longer supported (and new ones are quite expensive for something that mostly works).

I have done what you requested and it seems to me that the main difference is the following:

On the left you have the status when the VPN server is just turned on with everything working fine.

On the right, the status after rebooting the router (without any change in config from the previous state) where I no longer have internet access from local lan.

Screenshot1.png


My best,

MadMe

Before reboot (everything OK)
Code:
tun22     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1589 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1929 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:255586 (249.5 KiB)  TX bytes:1475237 (1.4 MiB)
-----------------------------------------------------------------------------------------------------
ip route show table main
10.0.0.111 dev eth0  proto kernel  scope link
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.150
10.8.0.0/24 dev tun22  proto kernel  scope link  src 10.8.0.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
127.0.0.0/8 dev lo  scope link
default via 10.0.0.111 dev eth0
-----------------------------------------------------------------------------------------------------
for i in 1 2 3 4 5; do echo "table ovpnc${i}"; ip route show table ovpnc${i}; done
table ovpnc1
table ovpnc2
table ovpnc3
table ovpnc4
table ovpnc5
-----------------------------------------------------------------------------------------------------
ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
-----------------------------------------------------------------------------------------------------

After Reboot (no Wan access)
Code:
tun22     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
-----------------------------------------------------------------------------------------------------
ip route show table main
10.0.0.111 dev eth0  proto kernel  scope link
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.150
10.8.0.0/24 dev tun22  proto kernel  scope link  src 10.8.0.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
127.0.0.0/8 dev lo  scope link
default via 10.0.0.111 dev eth0
-----------------------------------------------------------------------------------------------------
for i in 1 2 3 4 5; do echo "table ovpnc${i}"; ip route show table ovpnc${i}; done
table ovpnc1
10.0.0.111 dev eth0  proto kernel  scope link
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.150
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
10.8.0.0/24 dev tun22  proto kernel  scope link  src 10.8.0.1
127.0.0.0/8 dev lo  scope link
prohibit default
table ovpnc2
table ovpnc3
table ovpnc4
table ovpnc5
-----------------------------------------------------------------------------------------------------
ip rule
0:      from all lookup local
10001:  from 192.168.1.1 lookup main
10101:  from 192.168.1.0/24 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default
-----------------------------------------------------------------------------------------------------
 

eibgrad

Part of the Furniture
This is why dumps are so useful.

Something you didn't mention before is that in the second dump, you have an active OpenVPN client configured at the same time! And you are routing everything through it (192.168.1.0/24) w/ policy routing. But it has its default route blocked w/ a "prohibit default", suggesting the OpenVPN client has failed and you have the kill switch enabled. That explains why no internet access.

What I don't understand is why in the first dump there is no active OpenVPN client.

IOW, none of this seems to have anything to do w/ the OpenVPN server.
 

eibgrad

Part of the Furniture
P.S. One of the gotchas when it comes to having the OpenVPN server and client running at the same time is if they both should coincidentally end up using the same IP networks on their respective tunnels (e.g., 10.8.0.0/24). You can't allow that to happen or you'll have routing problems due to the ambiguity.
 

eibgrad

Part of the Furniture
Way back when, the old Merlin firmware used to make the killswitch persistent across a reboot, even if the OpenVPN client was otherwise disabled (that's no longer the case). Is that perhaps what's going on here? IOW, the OpenVPN client is OFF, but the killswitch is still active, but you don't realize that's the issue.
 

madme

New Around Here
Hello again eibgrad,

I didn´t mention that I had an active VPN client because I do not have one.

I do have a VPN client configured in the router that I haven´t used in a long time, but it is configured with “Automatic start at boot time = NO”. Somehow there seems to be some kind of interaction during boot time between the VPN Server and the configured VPN client (which still appears as not been started in the VPN – Status page).

Since I am not using the VPN client, I have reset it the to “default” and everything works fine now.

The issue is RESOLVED.

Thank you very much for pointing where to look.

Best regards,

M.
 

eibgrad

Part of the Furniture
Glad it's working.

As I said, if the OpenVPN client had its killswitch set to Yes, EVEN if it was otherwise OFF and had "Automatic start at boot time" set to No, the killswitch would still be active and block all access to the internet, both WAN and VPN. Returning the OpenVPN client to defaults presumably reset the killswitch back to No (the default), hence why it corrected things. It had NOTHING to do w/ any interaction w/ the OpenVPN server. That was a red herring.
 
Last edited:

madme

New Around Here
Hi eibgrad,

You know a lot more of this stuff than me. The killswitch has something to do with it but the booting process also affects the connection somehow.
  • NO VPN server configured, VPN client OFF --> WAN access OK
  • VPN Server(just) turned ON, VPN client OFF , NO reboot --> WAN access OK
  • VPN Server configured to turn ON, VPN client OFF AND reboot --> NO WAN access
BTW I did have the kill switch turned on. I recovered an old settings file and I am posting the vpn client details for reference.

Thanks,

M.

Screenshot 2022-07-21.png
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top