maxbraketorque
Very Senior Member
I've had a site-to-site VPN tunnel running smoothly between two ASUS routers for a few years now. I have been selectively installing alpha and beta versions of 386.3 as they were released without issue, and the site-to-site tunnel was working fine with the ASUS router OVPN client running 386.3_0 and the ASUS router OVPN server running 386.3_alpha1. This morning, I upgraded the server to 386.3_0, and after this, the site-to-site tunnel would connect without issue and is clearly connected from both ends, but data between the locations no longer flows, and attempts to ping get no response from either end. No OVPN connection errors were observed. I am not using any VPN Director rules with 386.3, and I didn't have any rules before that.
This tunnel is purely for site-to-site access, so the tunnel only transmits LAN traffic, and I use decimal addresses for accessing services across the tunnel, so the lack of data and connectivity through the tunnel is not a DNS issue, or at least I don't think it is. I found and ran Martineau's ChkVPNConfig script, and this returned a result stating that "RPDB rules will be misdirected for VPN Client 2 via eth0". Several weeks ago, I happened to run "ip rule show", "ip route", and "show table ovpnc2" for something I was doing with Jack Yaz, and the results of those commands today are exactly the same as they were two weeks ago.
This evening I can switch the OVPN server router back to 386.3_alpha1 to see if that resolves the issue, but does anyone have any thoughts on what else I can check? Currently, I only have access to the router running the OVPN client.
This tunnel is purely for site-to-site access, so the tunnel only transmits LAN traffic, and I use decimal addresses for accessing services across the tunnel, so the lack of data and connectivity through the tunnel is not a DNS issue, or at least I don't think it is. I found and ran Martineau's ChkVPNConfig script, and this returned a result stating that "RPDB rules will be misdirected for VPN Client 2 via eth0". Several weeks ago, I happened to run "ip rule show", "ip route", and "show table ovpnc2" for something I was doing with Jack Yaz, and the results of those commands today are exactly the same as they were two weeks ago.
This evening I can switch the OVPN server router back to 386.3_alpha1 to see if that resolves the issue, but does anyone have any thoughts on what else I can check? Currently, I only have access to the router running the OVPN client.