problem with connection between wan and device connected to vpn client

[frunzie]

Hello
The AC-86U runs on 384.19. I have 2x vpn client set up. I have a device (VU) assigned to one vpn client(tun13). I would like to connect to this device(VU) from outside via WAN. I have redirected the port, but there is no communication. There is communication only when I am connected via wifi. When the VU disconnects from the vpn client, the connection via the WAN is established. Already tried https://github.com/RMerl/asuswrt-merlin.ng/wiki/Policy-based-Port-routing-(manual-method) example 2 with no luck. Maybe is not possible?
ps. sorry for my english, its my foreign lauguage.

 

[eibgrad]

You can't remotely access a device over the WAN while it is simultaneously bound to the OpenVPN client. If that happens, the replies get routed over the VPN, which is NOT permitted by the stateful firewall (specifically reverse-path filtering). The stateful firewall requires that any remote access occur in and out of the same network interface on the router.

So either the target has to come off the OpenVPN client, or else you need to remotely access it over the VPN (assuming your OpenVPN provider supports it).

If you insist on the target being accessed over the WAN while connected to the VPN, another possible solution it to use a different form of PBR (policy based routing) than what's available w/ the router, one which is port based, assuming you can correctly isolate that specific traffic both to and from the target. But not all PBR implementations are created equal, and so I can't speak specifically to the one you mentioned regarding its effectiveness. FWIW, I recently helped some who had a similar need wrt a Plex server, so perhaps you might find that useful as a starting point.

Solved - 386.1_2: openvpn-event causes “Linux route add command failed”

Thanks for the link. Now I see why I was confused. I didn't realize table 254 was the main table. Usually when referencing tables, at least those well-known, you use the name, if only for reasons of clarity. ip rule add fwmark 0x7000/0x7000 table main prio 9990 Anyway, I have a problem w/...

www.snbforums.com

There are other options that may work depending on circumstances. For example, if you KNOW w/ certainty the public IPs of the remote client (your workplace, commonly visited wifi cafe, etc.), you can simply add static routes to the router that binds those public IPs to the WAN. That's by far the simplest solution, but it lacks practicality when roaming to unexpected locations, where obviously the public IP is far more unpredictable.

 

[GSpock]

Maybe is not possible?
ps. sorry for my english, its my foreign lauguage.

Hi,
yes, it is also possible to access your VU remotely while being protected by your VPN client on your router if your VPN provider allows port forward and provides you a "static ip".
After having defined the port fwd at your VPN provider side, you need to have a nat-start script on your router with the following commands:

iptables -D FORWARD -i tun13 -p tcp -d the_ip_of_your_vu --dport your_port -j ACCEPT
iptables -I FORWARD -i tun13 -p tcp -d the_ip_of_your_vu --dport your_port -j ACCEPT
iptables -t nat -I PREROUTING -i tun13 -p tcp --dport your_port -j DNAT --to-destination the_ip_of_your_vu

I have this config (with TorGuard) for my NAS and it works very well.

 

[frunzie]

Thanks for replying. Unfortunetly my vpn not supporting port forwarding but is good to know.
Will check Your eibgrad link/script and try implement it on my configuration. Getting to work on that now...

 

[frunzie]

Thanks again for the hints. I managed to achieve my intended goal. Another thing bothers me now. I have a "VU" device connected to VPNclient 1 and a "NAS" device connected to VPNclient 2. When I connect via wifi home communication to these devices is there. However, no communication with devices behind VPNclients if I connect to VPN server or IPsec server (do I need to add some static routes?), only communication with devices not connected to VPNclients.
Additional question - is it normal that being connected via wifi YAZFI it is not possible to log into the router's website?

VPNserver

VPNserver config

 

[eibgrad]

I assume you solved the original problem using static routes, given you posted a snapshot of the routing table. I'm only asking in case it has any relevance to your followup question (not sure at this point).

If I had to guess, I bet you have Routing Policy (strict) specified for the *local* OpenVPN clients. This is likely stripping out the route to the OpenVPN server's IP tunnel network (10.11.0.0/24) from their respective routing tables. Instead, you need to use the NON strict version of Routing Policy.

As far as YazFi, I can't speak to that issue. You'd have to ask the developer @Jack Yaz since that's his software.

 

[frunzie]

vpnc1 and vpnc2 are non strict routing policy. Thats not the case. And yes I solved earlier problem using static routes but before that i also have 2nd problem.

EDIT: Ok, dont know what i actually do but I changed some ports in vpnserver and started to work and now I can connect to vpnc devices. But still IPsec server cant connect to vpnc devices...

 

[eibgrad]

Then there must be some other routing conflict among all these VPNs. Dump the routing tables so we can see what that might be.

ip route
ip route show table ovpnc1
ip route show table ovpnc2

 

[eibgrad]

Btw, when you have this many VPNs in the mix (client and server), a common problem is having more than one w/ the same IP network on the tunnel, which then creates routing conflicts. It's something you need to keep in mind since it's not something you would typically notice unless you were looking for it. This is esp. true when connecting multiple OpenVPN clients to the *same* OpenVPN provider which only differ in their choice of servers.

That's why I want to see the routing tables, to see if that's the case.

 

[eibgrad]

FWIW, I also noticed your OpenVPN server port is 84. It's generally NOT a good idea to use any of the well-known ports (0-1023) since ISPs are known to frequently block them, even if the port isn't defined as yet. Sometimes ISPs just block them all (inbound *and* outbound), then make a few exceptions for necessary protocols. So I don't recommend it. Better to use ports well outside this range, perhaps 10000 and above. Just less chance for issues. But ultimately that's your call.

 

[frunzie]

Thanks for the tip about VPNserver, changed port as You mentioned.

 

[eibgrad]

Well I can immediately see the problem. The OpenVPN server's tunnel network interface (tun21) is NOT in either of the OpenVPN client's routing tables! And that's probably do to a timing issue, where the OpenVPN clients are getting established and connected *before* the OpenVPN server is established. So naturally the OpenVPN server's network interface never gets copied from the main routing table and into either of the OpenVPN client's routing tables. And therefore, no route exists being the OpenVPN server and any local devices bound to the local OpenVPN clients.

Frankly, I'm a little surprised the router would allow this to happen. Seems to me it should recognize this as a real possibility when the OpenVPN server(s) is concurrently active w/ the OpenVPN client(s). Just makes sense to delay starting the clients until the OpenVPN server(s) is established.

Of course, the same thing could happen if you started all of them manually, and started the OpenVPN clients before the OpenVPN server.

One way to confirm the problem is to autostart the OpenVPN server, but temporarily do NOT autostart the OpenVPN clients. Reboot and wait until the OpenVPN server is well established, then manually start the OpenVPN clients. I suspect you'll now see the tun21 network interface in both the ovpnc1 and ovpnc2 routing tables, and things will work as expected.

 

[frunzie]

Wow, That was the case, it's just as You described, enabled vpn clients manually after reboot and it is working flawless. Added an automated start of vpnc after system boot with 20s delay in services-start script.

Thank you very much for your help and your time.

 

[eibgrad]

Glad to hear you got it working.

For the long term, it seems to me this should be corrected by @RMerlin. While it's a relatively easy fix once you know the problem, it's difficult for the average user to detect it. Better that the router automatically recognize this potential problem so that when any autostart'd OpenVPN client is started (at least when using Routing Policy), any autostart'd OpenVPN server is always started first so its network interface gets included into the OpenVPN client's routing table.

 

[RMerlin]

This is purely a matter of point of view. Another user might actually want the exact opposite to happen if they wanted to add client routes to their server config. I don't see anything that needs to be "corrected" here, it's simply you are expecting something to happen in a specific order, and changing this would cause issues for other users who were relying on the existing behaviour.

 

[eibgrad]

This is purely a matter of point of view. Another user might actually want the exact opposite to happen if they wanted to add client routes to their server config. I don't see anything that needs to be "corrected" here, it's simply you are expecting something to happen in a specific order, and changing this would cause issues for other users who were relying on the existing behaviour.

Fair enough, but as it stands currently, are you saying it's predictable, that it works this way by design? IOW, when configured to autostart both the clients and servers, and after a reboot, I'm NOT going to find the OpenVPN server's network interface within the OpenVPN client's routing table, NOT ever, right? It's guaranteed NOT to happen.

 

[RMerlin]

Fair enough, but as it stands currently, are you saying it's predictable, that it works this way by design?

No, there was simply no intended order as there wasn't a single order that made more sense than the other.

 

[eibgrad]

No, there was simply no intended order as there wasn't a single order that made more sense than the other.

So you're saying it's random? That makes no sense. You're claiming that to do as the OP did, which was to force a specific order, would "cause issues for other users who were relying on the existing behaviour". Users are depending on unpredictable, random behavior?! That's a contradiction.

 

[RMerlin]

So you're saying it's random?

I didn't say that. I said that there was no specific chosen order, it was set to whatever order the line of codes happened to be entered.

 

[eibgrad]

I didn't say that. I said that there was no specific chosen order, it was set to whatever order the line of codes happened to be entered.

Let's just agree to call it "undefined".

My concern is that it's not easy for the user to detect the problem. Users are going to assume the OpenVPN server's network interface is just part of the routing system, like every other network interface. But in this one narrow case of having Routing Policy enabled, and due to an implementation detail, it's not.

I realize that trying to coordinate things within the system is often problematic. But at least on bootup, it would seem reasonable to recognize this potential problem and adjust accordingly. And it seems like a simple fix; the starting of the OpenVPN server(s) should receive priority over the OpenVPN client(s), at least when Routing Policy is enabled.

I understand the argument that users now have an expectation regarding current behavior. Nonetheless, it's hard to imagine any would expect/prefer to be denied access to the LAN (esp. partial) just because Routing Policy is enabled. The OpenVPN server specifically has an option for that purpose ("Client will use VPN to access"). Ironically, one of the benefits of using the OpenVPN server is that you *can* access LAN clients when they're bound to the OpenVPN client(s), something NOT true when accessed over the WAN (at least if it wasn't for this bug).

Anyway, I've made my case and the matter is closed AFAIC.