vpn problems in asuswrt merlin 3004.388.8

[CKret]

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 the remote subnet. Unless you truly want the Internet connection to also go through the tunnel.

No I have No redirection set with the original rules. Redirection is only on the specific subnets of all sites.
Internet is never redirected through the tunnels. (If that is what you are suggesting).

 

[eibgrad]

No I have No redirection set with the original rules. Redirection is only on the specific subnets of all sites.
Internet is never redirected through the tunnels. (If that is what you are suggesting).

I believe what @CKret is suggesting is that he has NONE/NO for redirection, which (according to @RMerlin) is one of the cases when iif is introduced to the ip rules. And now, because he depends on established routes between the sites which exist in the OpenVPN client's routing table, they becomes inaccessible to any network interface other than the LAN (br0). A classic victim being chained tunnels, where the input interface is something other than br0 (e.g., tun21).

IOW, the VPN Director plays no role under his scenario. It isn't needed. The routing table determines what goes through the tunnel based on the intended destination IP, NOT the source IP.

P.S. I suppose if enabling the VPN Director does NOT insert the iif to the rule, then he could use that as a workaround. Nothing says he must add any rules, esp. since he doesn't need any.

 

[eibgrad]

In all honesty, I think we can all agree this is mighty confusing, and difficult to follow. We're dealing w/ multiple changes, affecting different things, under different scenarios.

 

[CKret]

In all honesty, I think we can all agree this is mighty confusing, and difficult to follow. We're dealing w/ multiple changes, affecting different things, under different scenarios.

I fully agree.

This issue can be managed until the next release. Hopefully 388.8_2 but if not then 388.9.
There are probably very few affected by this and those who are have the knowledge to come to this forum.

 

[eibgrad]

I fully agree.

This issue can be managed until the next release. Hopefully 388.8_2 but if not then 388.9.
There are probably very few affected by this and those who are have the knowledge to come to this forum.

As I just added above to my prior comment, I suspect if you enable the VPN Director, it will serve as a workaround. You shouldn't see the iif anymore in the ip rules. I didn't realize at the time I suggested changing the ip rules w/ that other workaround that the choice of no/all/vpn-director made a difference in when the iif was applied. It's just not intuitive to someone using site2site that the VPN Director would be useful. Typically it isn't, but for the current scenario, it apparently is.

P.S. Just noticed from a prior post the above didn't work for you. Seems you will need to add rules for each destination across the tunnel. As I said before, that wouldn't normally be necessary since the static routing is already established, so it's just redundant. But at least it gets rid of the iif.

 

[CKret]

P.S. I suppose if enabling the VPN Director does NOT insert the iif to the rule, then he could use that as a workaround. Nothing says he must add any rules, esp. since he doesn't need any.

As I just added above to my prior comment, I suspect if you enable the VPN Director, it will serve as a workaround. You shouldn't see the iif anymore in the ip rules. I didn't realize at the time I suggested changing the ip rules w/ that other workaround that the choice of no/all/vpn-director made a difference in when the iif was applied. It's just not intuitive to someone using site2site that the VPN Director would be useful. Typically it isn't, but for the current scenario, it apparently is.

No. Enabling VPN Director doesn't serve as a workaround since the needed rule is missing completely.
The rule is deleted when enabling VPN Director.
The "faulty" rule is re-inserted when VPN Director is disabled.

The workaround I use right now is a cron job that once a day changes the rule to the correct one since a reboot will re-insert the "fauly" rule.

 

[eibgrad]

No. Enabling VPN Director doesn't serve as a workaround since the needed rule is missing completely.
The rule is deleted when enabling VPN Director.
The "faulty" rule is re-inserted when VPN Director is disabled.

The workaround I use right now is a cron job that once a day changes the rule to the correct one since a reboot will re-insert the "fauly" rule.

Reread my last comments, I just updated them.

 

[CKret]

Reread my last comments, I just updated them.

I concur.

The issue can be mitigated and managed.
We are aware of the root cause.
What's left is for @RMerlin to decide how to solve. ;P

 

[eibgrad]

I concur.

The issue can be mitigated and managed.
We are aware of the root cause.
What's left is for @RMerlin to decide how to solve. ;P

I don't have the ability to try any of this myself. I don't have a suitable router or firmware. What I'd appreciate knowing is if enabling the VPN Director *and* adding a rule for each destination IP network available across the tunnel works. If it does, I want to formally publish that as the workaround, rather than mucking w/ the ip rules directly, cron jobs, etc. But I need your help.

 

[RMerlin]

As I just added above to my prior comment, I suspect if you enable the VPN Director, it will serve as a workaround.

That was my intention indeed - temporary work around. If you need traffic redirected, create rules. If not - don't, just rely on routes pushed from the server.

 

[RMerlin]

What's left is for @RMerlin to decide how to solve.

It's already established that there is a bug in 3004.388.8 where it's specifying a network interface in All and None mode, as that fix didn't get carried over from 3006 when it was fixed there. So, that solution is to apply the same fix as 3006 received during development. That bug does not exist in VPN Director mode, which is why I suggested as a temporary workaround to switch to it, and create VPN Director rules if you need traffic redirection, or don't create any rule if you don't need traffic redirected.

 

[lgkahn]

That was my intention indeed - temporary work around. If you need traffic redi

seems to work in my case these are the two rules vpn director added. however i am back on 8,7.0 as lack of rog in next release.
but it did work in beta 1 as well when i had it installed.

 

[eibgrad]

seems to work in my case these are the two rules vpn director added. however i am back on 8,7.0 as lack of rog in next release.
but it did work in beta 1 as well when i had it installed.

Thanks!

So for now, that's the secret sauce for the scenario of chained tunnels, or anything requiring access to the OpenVPN client other than the LAN (br0). You need to enable the VPN Director, which gets rid of the iif in the ip rules. But you also need to add rules to the VPN Director for each remote IP network available across the tunnel (I assume providing the destination IP network(s) is sufficient). Normally that's not necessary w/ site-to-site, since the static routing is already known to the system.

A little convoluted, for sure. And I don't know if that's the long term solution (I suspect not given recent comments by @RMerlin, but we'll see). I think it's better than hacking the ip rules w/ a cron job or an openvpn-event script.

 

[RMerlin]

The test builds are currently compiling.

I wish my new Zen 5 build was ready to speed up the process, but now AMD has just announced a two weeks delay on the launch. Somebody must really hate me... My previous PC had me staring at the PC parts in a corner of my living room for three months as the only way to get a CPU back then was through scalpers. I had to wait for a reliable scalper not asking a 200% markup on the MSRP before I could build the system.

 

[RMerlin]

Please try the test builds uploaded here:

OneDrive

www.asuswrt-merlin.net

 

[iBest]

Please try the test builds uploaded here:

OneDrive

www.asuswrt-merlin.net

Good morning,

I can confirm, for my scenario, test build IS WORKING !

Thank you very much man !

 

[CKret]

Please try the test builds uploaded here:

OneDrive

www.asuswrt-merlin.net

I also can confirm that this test build is working.

Thank you!

 

[moreamazingnick]

Please try the test builds uploaded here:

OneDrive

www.asuswrt-merlin.net

I can also confirm that this works with my setup.
Thank you so much!
Best Regards
Nicolas

 

[Unetwork]

Thanks to @eibgrad and @RMerlin for these long explanations.

If I can add anything, here are the problems I encounter when upgrading to version 388.8 (AX88U router).

1. I've had these settings in place for a long time and when I update the router to version 388.8, I lose control and access to the WEB interface.
I have to do a complete WPS reset and start from scratch. It's very frustrating.

2. The only solution I've found so far to get around this problem is to add these two rules with the new 388.8 firmware.
once applied, I no longer lose access to the web interface. On the other hand, I no longer have access to the Internet, which is odd.
I have to disable the Killswitch, whereas before it was always on.

Thanks again for all your hard work.

 

[elorimer]

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.