vpn problems in asuswrt merlin 3004.388.8

[Unetwork]

I don't know if your help was intended for me, but thanks anyway, except that I only use one router...
My use is very simple. I'm just reporting the problems I have with the 388.8 (see my post above).
I hope this can be resolved.

 

[elorimer]

don't know if your help was intended for me,

No. In the highly constructive conversations going on between RMerlin and eibgrad, it sounded like neither had a site to site platform to evaluate their theories. I thought my data point might help them.

 

[eibgrad]

This may help. My site to site setup seems to be working:

Site A: Ax88 with 388.7 with OpenVPN server. 192.168.50.0/24 LAN. (I don't have physical access to this router so I'm not updating it to .8 yet)
Site B: AX86U Pro with 388.8 (and also the test build). 192.168.10.0/24 LAN.

Site B connected to Site A, site to site, over OVPNC2, no killswitch, with a VPN director rule directing any traffic to 192.168.50.0/24 over the tunnel.
Site B two specific devices with everything directed over OVPNC2, no killswitch, seems to be working.
Site B nine specific devices with everything directed over OVPNC3, killswitch, seems to be working but I can't really tell (air conditioners).
Site B, everything else over WAN. Seems to be working.

Access to Site A router at 192.168.50.1 from Site B, no issues. GUI is set to LAN access only and not reachable from the public IP or DDNS address. Devices on Site A or Site B can reach devices on the other, including the Site B GUI.

Not sure it is relevant, but the upgrade of the AX86 Pro from .7 to .8 required a reset, probably because of the killswitch in .7 for the nine device rule.

Remember, the problem for most ppl is when they attempt to access the OpenVPN client's tunnel from something other than the local LAN (br0), such as an OpenVPN server co-located w/ the OpenVPN client (i.e., chained tunnels). Remote clients of that OpenVPN server can NOT be routed through the OpenVPN client of the site-to-site connection if the ip rules are limited to the LAN (bro) due to the injection of the iif option.

IOW, if you do NOT meet this very specific configuration, you won't be affected. Just having a normal site-to-site configuration where each side addresses the other's IP network(s) from their respective LANs will continue to work normally.

If you do meet this specific configuration, we've since come to learn that the iif option is only injected if you specify No or All for "Redirect internet traffic through tunnel" on the OpenVPN client. Normally you would specify No for a site-to-site configuration since (if configured properly), static routing is used on each side to make the IP networks available across the tunnel known to the routing tables. Use of the VPN Director, while it will still work, is actually superfluous (again, provided you've properly configured the static routing).

Given all the above, we are now recommending the use of the VPN Director as a workaround to those who are affected. So had YOU meet the requirements of this bug, the fact you're already using the VPN Director would have protected you. IOW, you unknowingly inoculated yourself from its effects due to your (imo) misconfiguration (not unless it is your intention to restrict access across the tunnel).

On a side note, I notice that a lot of users who configure site-to-site also mistakenly NAT the tunnel on the OpenVPN client side. Again, this is unnecessary provided you have correctly configured the static routing.

All that said, @RMerlin now has a fix that apparently is working for those who have tried it.

vpn problems in asuswrt merlin 3004.388.8

Based on the original rules, you have Redirection set to "All". In that case, VPNDirector will require you to create the two rules I mentionned in my post, otherwise nothing will be routed through the VPN. EDIT: Tho generally in a site2site tunnel, you don't want to redirect everything - only...

www.snbforums.com

 

[elorimer]

IOW, you unknowingly inoculated yourself from its effects due to your (imo) misconfiguration (not unless it is your intention to restrict access across the tunnel).

I don't mean to hijack the thread, but I'm not sure if follow the misconfiguration.

Site B client connects to Site A server with no NAT. My VPN director has a rule that specifies that every device that wants to reach the Site A Lan goes over the tunnel. Three more rules specify that specific IPs on Site B route everything over the tunnel. That is to make those devices geolocate to Site A. Another rule specifies that nine devices connect over a different tunnel which is Nat'd to geolocate them to a third site. Everything else at Site B goes out the WAN.

 

[eibgrad]

I don't mean to hijack the thread, but I'm not sure if follow the misconfiguration.

Site B client connects to Site A server with no NAT. My VPN director has a rule that specifies that every device that wants to reach the Site A Lan goes over the tunnel. Three more rules specify that specific IPs on Site B route everything over the tunnel. That is to make those devices geolocate to Site A. Another rule specifies that nine devices connect over a different tunnel which is Nat'd to geolocate them to a third site. Everything else at Site B goes out the WAN.

As I said, if your routing is *conditional*, then yes, use of the VPN Director is needed, it makes sense. But for site-to-site, that's often not the case. More typically, if a device wants to access another device across the tunnel, it just does so, and the static routing makes that possible w/ no other changes to the configuration.

What happened w/ this bug is that ONLY those who are NOT restricting access to the tunnel were affected, such as those specifying No for the "Redirect internet traffic through tunnel" option and relying solely on static routing.

Frankly, it's all a bit confusing, esp. since whether you were even affected comes down to very specific configuration options. So confusing, I even questioned whether to respond to your comments at all, esp. if it's working for you. But it also seemed like an opportunity to further clarify exactly what those specific configuration options are, and even though you didn't meet them, others might benefit.

 

[RMerlin]

Does this update also address the issues some were having in reaching the router's webui?

 

[Unetwork]

Does this update also address the issues some were having in reaching the router's webui?

I have this problem but I can't flash the new beta at the moment, really sorry, I need the network and I can't risk breaking everything.
If someone else could test it, that would be great.
Thanks in any case for making the corrections.

 

[Dedel66]

Please try the test builds uploaded here:

OneDrive

www.asuswrt-merlin.net

Downloaded this file:

https://lostrealm-my.sharepoint.com/personal/merlin_lostrealm_ca/_layouts/15/onedrive.aspx?sw=bypass&bypassReason=abandoned&ga=1&id=%2Fpersonal%2Fmerlin%5Flostrealm%5Fca%2FDocuments%2FAsuswrt%2DMerlin%2FTest%20builds%2FRT%2DAX88U%5FPRO%5F3004%5F388%2E8%5F1%2Dg908dbf3334%2Ezip&parent=%2Fpersonal%2Fmerlin%5Flostrealm%5Fca%2FDocuments%2FAsuswrt%2DMerlin%2FTest%20builds

Getting this result:

3004.388.8_beta1???


BTW: I´ve got no problem reaching router´s webui via wireguard with an android client and ipv6.

 

[RMerlin]

3004.388.8_beta1???

You've either flashed the wrong file, or the flash procedure didn`t complete.

 

[Dedel66]

You're right: I mixed up some files so the flash was incomplete. It's too late after a long week of work.

SORRY!!!

 

[Karmatron]

Please try the test builds uploaded here:

OneDrive

www.asuswrt-merlin.net

This test build fixed the issue I posted here. Thank you very much!

 

[iBest]

Please try the test builds uploaded here:

OneDrive

www.asuswrt-merlin.net

Hello,

Running all kind of tests with this build, everything looks in order.
Also tried mapping some others problems described with the latest build ... no issues.
I think this can go public as <<Release>> build if everything checks on your end , too.

Have a nice weekend

 

[maxbraketorque]

I needed this fix for my ASUS router site-to-site bi-directional OVPN to fully work in both directions.