vpn problems in asuswrt merlin 3004.388.8

[Purana]

Client side v388.7 dump files, both sites can access each other:

Server side v388.8 dump files, client side can access server side normally, but server side failed to access client side.

 

[Purana]

Server side v388.8 dump files, client side can access server side normally, but server side failed to access client side.

Server side v388.8 dump files, client side can access server side normally, but server side failed to access client side.

 

[Purana]

Server side v388.8 dump files, client side can access server side normally, but server side failed to access client side.

Client side v388.8 dump files, client side can access server side normally, but server side failed to access client side.

 

[Purana]

Client side v388.8 dump files, client side can access server side normally, but server side failed to access client side.

Client side v388.8 dump files, client side can access server side normally, but server side failed to access client side.

 

[moreamazingnick]

ip rule del iif br0 lookup ovpnc1 prior 10001
ip rule add lookup ovpnc1 prior 10001

That's NOT a long-term solution. I just want to verify that indeed it is the problem.

that is exactly what fixes the issue in my setup!
I hope this will somehow find the way back to next build.
Thank you so much for your effort.

Best Regards
Nicolas

 

[Purana]

ip rule del iif br0 lookup ovpnc1 prior 10001 ip rule add lookup ovpnc1 prior 10001

My problem is resolved after deploying the code, thank you for your help.

 

[iBest]

Hi!

In the fw topic I had also tried to compare the logs and found this

\

Thanks you guys for your time and attention over this problem !
Will wait for a new fw with the fix in it, but, knowing there is already a temp fix is very good news !

Regards

 

[CKret]

Ok, I want to get very precise here to make absolutely sure I understand the issue.

When you say Site2Site is OK, what exactly does that mean? Are you saying that IP network(s) behind the OpnSense router are accessible from the IP network(s) behind the RT-AX58U, and vice versa?

Because your reference to "the two tunnels" initially had me puzzled. But I now think what you mean is that the problem is limited to the iPhoneMac, when you are *chaining* OpenVPN tunnels.

Well here's what I found. In the configuration that works, the ip rules database is as follows:

0:    from all lookup local
10001:    from all lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

BUT, when it's NOT working, that same ip rules database is as follows:

0:    from all lookup local
10001:    from all iif br0 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

Notice the difference. In the latter case, the rule is *limited* to those source IPs coming from the LAN (br0). In the former case, it's *anything*, be it the LAN, WAN, VPN, whatever. And in the case of the iPhone/Mac, they are NOT coming from the LAN, but the OpenVPN server's tunnel (e.g., tun1)! So they will never be routed over to the ASUS router.

I have no idea why this was changed, but it seems to me this is the issue. You could try replacing that rule w/ the prior form of the rule to see if it now works.

ip rule del iif br0 lookup ovpnc1 prior 10001
ip rule add lookup ovpnc1 prior 10001

That's NOT a long-term solution. I just want to verify that indeed it is the problem.

I can confirm that the same faulty rule existed on my AX68U client.
After changing the rule everything works again as expected.

 

[eibgrad]

I can confirm that the same faulty rule existed on my AX68U client.
After changing the rule everything works again as expected.

Whether it's "faulty" remains an open question. It certainly is going to break things (as already seen). But there has to be a reason for that additional qualification of the LAN (br0) on the rule. And so far, that remains unclear. And my concern is if we simply return to the old ip rule, what will be the effect? What will that rollback mean to whatever was the intended purpose of the change?

 

[RMerlin]

The new killswitch implementation and its related VPN architectural changes spent around two months in public beta. I wish more people with these kind of unusual setups tested things during the beta cycle.

Now I need to find time to do a full lab setup with two separate routers, two separate LAN clients (behind each router) and try to reproduce the whole setup. I don't know when I'll have the time to do such a test setup, so it may take a while.

Thanks @Purana for providing the details. I'll have a look at them later.

 

[RMerlin]

And my concern is if we simply return to the old ip rule, what will be the effect?

That won't happen. Based on my notes, I think the problem was that without it, there was no way to isolate separate networks that are created through Guest Network Pro, so if you assign a VPN client to a specific GN, only that GN interface should be using that table.

I see no logical reason why traffic coming from another interface than br0 (in the case of a single LAN) would need to go through a VPN tunnel. Something else might be at play there. I just need to find some time to try to reproduce a similar setup.

Thanks for your efforts in digging through this, it will certainly be helpful.

 

[iBest]

If you consider and you have time, can you push a fix fw with the current solution ?
Until you have the time for let's say a proper firmware ?

Anyway, thanks !

 

[RMerlin]

If you consider and you have time, can you push a fix fw with the current solution ?

No, because that's not a solution. That only creates a different problem.

 

[iBest]

I see. In this case, I will wait for your real fix on this matter.
Thanks for all your efforts and your time.

Regards

PS: If there will be some tests before a release, i can help since I have 2 sites with 2 diff subnets interconnected and one injected tunnel in between

 

[CKret]

The new killswitch implementation and its related VPN architectural changes spent around two months in public beta. I wish more people with these kind of unusual setups tested things during the beta cycle.

Now I need to find time to do a full lab setup with two separate routers, two separate LAN clients (behind each router) and try to reproduce the whole setup. I don't know when I'll have the time to do such a test setup, so it may take a while.

Thanks @Purana for providing the details. I'll have a look at them later.

I understand your frustration.

However... I do not personally have the time nor inclination to test every beta version that comes around.
I've my setup of 3 distinct sites interconnected. They are half a world apart. If something happens in Europe that prohibits me to connect to the site I cannot be there (on site) to solve it when I'm in Asia.
Luckily I usually have someone else technically proficient on site that I can instruct.

I have contributed to the firmware and will be doing so going forward.
If there is anything you'd need help with regarding the lab setup then I will assist.

 

[RMerlin]

However... I do not personally have the time or inclination to test every beta version that comes around.

I understand, and it's ok if someone choses not to risk their production network with beta code - that makes perfect sense. Running beta code is definitely not for everyone. I just wish more varied setups were getting testing during these beta cycles.

If there is anything you'd need help with regarding the lab setup then I will assist.

Thanks. But at this time, it's largely a matter of finding the time to reproduce things. There are a number of different scenarios involved here, where for some people it's just their inability to reach their router's webui when using a VPN client, while for others it's having site2site tunnels where they are having difficulties either routing Internet traffic or reaching the remote router's webui (I haven't read in details all the discussions on these, I just had a quick glance at them these past few days).

 

[RMerlin]

After comparing the VPN code between 3006 (where I originally developed and tested the new VPN handling code) and 3004, it seems some of the 3006 changes are missing. For instance, in 3006 I no longer specify an iif interface, while in 3004 I specify it only when Redirection is set to either "NONE" or "ALL". So I had things backward in my previous posts trying to explain the iif interface. The interface should NOT be there, and the issue experienced by some may actually be the same issue I experienced myself during original development...

Currently, the interface is only specified when redirection is set to None or All. If you have the issue caused by the presence of the interface, try switching to VPNDirector instead. Depending on your original configuration:

• f it was set to "None", then you don't need to change anything else in VPNDirector - just enable it.
• If it was set to "All", then create two rules:
  • One rule with the router's IP, set to WAN
  • One rule for the whole LAN subnet (i.e. 192.168.50.0/24), set to the VPN client

Please try these changes and post your results.

 

[CKret]

After comparing the VPN code between 3006 (where I originally developed and tested the new VPN handling code) and 3004, it seems some of the 3006 changes are missing. For instance, in 3006 I no longer specify an iif interface, while in 3004 I specify it only when Redirection is set to either "NONE" or "ALL". So I had things backward in my previous posts trying to explain the iif interface. The interface should NOT be there, and the issue experienced by some may actually be the same issue I experienced myself during original development...

Currently, the interface is only specified when redirection is set to None or All. If you have the issue caused by the presence of the interface, try switching to VPNDirector instead. Depending on your original configuration:

• f it was set to "None", then you don't need to change anything else in VPNDirector - just enable it.
• If it was set to "All", then create two rules:
  • One rule with the router's IP, set to WAN
  • One rule for the whole LAN subnet (i.e. 192.168.50.0/24), set to the VPN client

Please try these changes and post your results.

These rules work correctly:

0: from all lookup local
10005: from all lookup ovpnc5
32766: from all lookup main
32767: from all lookup default

Site2Site working properly.

When VPN director is enabled then the following rules exist:

0: from all lookup local
32766: from all lookup main
32767: from all lookup default

Site2Site not working properly.

Turning off VPN director, then the "faulty" rule is introduced again. Even if the rule was changed to be "correct" (before VPN director was turned on).

0: from all lookup local
10005: from all iif br0 lookup ovpnc5
32766: from all lookup main
32767: from all lookup default

Site2Site not working properly.

 

[RMerlin]

These rules work correctly:

With VPN director enabled then the following rules exist:
Site2Site not working properly.

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.

 

[lgkahn]

Based on the original rules, you have Redirection set to "All". In that case, VPNDire

so is this why when i posted back when beta 1 first came out that my vpn was not working.. i could only ping 1 direction with redirect none that i had to add the follwing director rule to get it working again and change not to use the direcor?