[SOLVED] OpenVPN server and Client not allowed at same time?

[siddhartha]

It seems to me that if it's not considered an issue to fix permanently in the firmware, then it can just be an option "Add [server] route to these clients:"

 

[Clint Eastwood]

Does this same issue occur running an IPsec server and L2TP client concurrently? I can't test this out myself as own AC68U.

 

[eibgrad]

Does this same issue occur running an IPsec server and L2TP client concurrently? I can't test this out myself as own AC68U.

Not likely.

Remember, the OP was using PBR (policy based routing) for his local OpenVPN client. And given the way PBR is implemented, it creates an alternate routing table for those clients bound to the local OpenVPN client. And the alternate routing table is always initialized based on the contents of the main routing table AT THE TIME the OpenVPN client was established. If the OpenVPN server is started *after* the OpenVPN client, its network interface makes it into the main routing (as always), but NOT the alternate routing table. Hence, those clients bound to the local OpenVPN client via PBR are unreachable by clients of the OpenVPN server (and vice versa). They don't have the necessary routes in their alternate routing table to communicate with each other.

It's a timing problem. And my script corrects it by monitoring the start of any OpenVPN server, and copying its network interface into the alternate routing table of any active OpenVPN clients.

So if you're NOT using PBR (whether one developed for OpenVPN or some other VPN client), then you're unlikely to have the same thing happen, since everything is likely using the same and only main routing table.

 

[chongnt]

Not likely.

Remember, the OP was using PBR (policy based routing) for his local OpenVPN client. And given the way PBR is implemented, it creates an alternate routing table for those clients bound to the local OpenVPN client. And the alternate routing table is always initialized based on the contents of the main routing table AT THE TIME the OpenVPN client was established. If the OpenVPN server is started *after* the OpenVPN client, its network interface makes it into the main routing (as always), but NOT the alternate routing table. Hence, those clients bound to the local OpenVPN client via PBR are unreachable by clients of the OpenVPN server (and vice versa). They don't have the necessary routes in their alternate routing table to communicate with each other.

It's a timing problem. And my script corrects it by monitoring the start of any OpenVPN server, and copying its network interface into the alternate routing table of any active OpenVPN clients.

So if you're NOT using PBR (whether one developed for OpenVPN or some other VPN client), then you're unlikely to have the same thing happen, since everything is likely using the same and only main routing table.

Very nice script. I have been adding the route using vpnserverX-up script. Since I run wireguard as well, I have the same for wg2X-up script. Your approach is much nicer and requires basically no further editing if I were going to turn up another ovpn client. Will try out your script and see how to fit it into wireguard perspective as well.

Spoiler: vpnserver1-up

#add route for tun21 remote dial-in to access hosts routed to other vpn client
ip route del "$ovpn_server1_subnet" dev tun21 table ovpnc1 2>/dev/null
ip route del "$ovpn_server1_subnet" dev tun21 table ovpnc3 2>/dev/null
ip route del "$ovpn_server1_subnet" dev tun21 table 121 2>/dev/null
ip route del "$ovpn_server1_subnet" dev tun21 table 122 2>/dev/null
ip route add "$ovpn_server1_subnet" dev tun21 table ovpnc1
ip route add "$ovpn_server1_subnet" dev tun21 table ovpnc3
ip route add "$ovpn_server1_subnet" dev tun21 table 121
ip route add "$ovpn_server1_subnet" dev tun21 table 122

 

[chongnt]

@eibgrad, would you help to look into my openvpn-event script? The script already exists so I have to manually add it in. I am not able to paste it here so I try to put it in pastebin.

original /jffs/scripts/openvpn-event:

#!/bin/sh
[ -s /jffs/scripts/x3mRouting/openvpn-event ] && sh /jffs/scripts/x3mRouting/openvpn-event $@

original /jffs/scripts/x3mRouting/openvpn-event

/jffs/scripts/x3mRouting/openvpn-event - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

I try to add your script into /jffs/scripts/x3mRouting/openvpn-event. I have no idea how the lock portion works so I temporarily omitted this part in my draft. I am also not sure if this is ok as I have duplicate some part for table 12x for wireguardvpn client. Here is my draft:

draft /jffs/scripts/x3mRouting/openvpn-event - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

 

[eibgrad]

@eibgrad, would you help to look into my openvpn-event script? The script already exists so I have to manually add it in. I am not able to paste it here so I try to put it in pastebin.

original /jffs/scripts/openvpn-event:

#!/bin/sh
[ -s /jffs/scripts/x3mRouting/openvpn-event ] && sh /jffs/scripts/x3mRouting/openvpn-event $@

original /jffs/scripts/x3mRouting/openvpn-event

/jffs/scripts/x3mRouting/openvpn-event - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

I try to add your script into /jffs/scripts/x3mRouting/openvpn-event. I have no idea how the lock portion works so I temporarily omitted this part in my draft. I am also not sure if this is ok as I have duplicate some part for table 12x for wireguardvpn client. Here is my draft:

draft /jffs/scripts/x3mRouting/openvpn-event - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

It's probably best to follow the pattern established by x3mRouting and just have the openvpn-event script call my script after calling the x3mRouting script.

SCRIPT_DIR='/jffs/scripts/merlin-ovpn-sync-routes-66726'
SCRIPT="$SCRIPT_DIR/openvpn-event"
mkdir -p $SCRIPT_DIR
mv /jffs/scripts/openvpn-event /jffs/scripts/openvpn-event.bak
curl -kLs pastebin.com/raw/kTThBV46 | tr -d '\r' | sh
mv /jffs/scripts/openvpn-event $SCRIPT_DIR
mv /jffs/scripts/openvpn-event.bak /jffs/scripts/openvpn-event
echo '[ -s '$SCRIPT' ] && sh '$SCRIPT' $@' >> /jffs/scripts/openvpn-event
:

 

[chongnt]

It's probably best to follow the pattern established by x3mRouting and just have the openvpn-event script call my script after calling the x3mRouting script.

SCRIPT_DIR='/jffs/scripts/merlin-ovpn-sync-routes-66726'
SCRIPT="$SCRIPT_DIR/openvpn-event"
mkdir -p $SCRIPT_DIR
mv /jffs/scripts/openvpn-event /jffs/scripts/openvpn-event.bak
curl -kLs pastebin.com/raw/kTThBV46 | tr -d '\r' | sh
mv /jffs/scripts/openvpn-event $SCRIPT_DIR
mv /jffs/scripts/openvpn-event.bak /jffs/scripts/openvpn-event
echo '[ -s '$SCRIPT' ] && sh '$SCRIPT' $@' >> /jffs/scripts/openvpn-event
:

Thank you so much @eibgrad. This is very neat and working very well.

 

[eibgrad]

FYI. I thought it worth mentioning that we have another possible solution to this problem. FULL CREDIT goes to @macdis.

Solved - OpenVPN server not starting at boot

Hi all, I'm having a problem with firmware 386.4 on my RT-AX88U. I have set up an OpenVPN server, which works as expected on its own. And I have set up an OpenVPN client, which works as expected on its own. The problem: if I have them both configured, then the server won't start at boot...

www.snbforums.com

While helping him work on an unrelated problem w/ a concurrently active OpenVPN server and client, I noticed he had the following policy rule in the VPN Director.

192.168.50.151 10.99.0.0/24 WAN

At first I was baffled, but then it dawned on me he was using this technique to get around the problem identified in this thread! And that is to force the replies from remote OpenVPN clients and into the LAN, to be routed back via the main routing table, where the OpenVPN server's network interface is always specified (even if not necessarily among the various OpenVPN clients due to timing issues).

It just never dawned on me to consider this approach, probably because it's counter-intuitive given the Iface of the rule says WAN. But in fact it's NOT using the WAN, but tun22 (it's server #2 in his case).

At first I wasn't 100% sure it was safe and might not have some unintended consequences, but so far, I don't see any. The nice thing is it avoids having to use scripting. Even so, it only works if you're using policy rules, and doesn't really solve the problem permanently. But I thought it's still worth mentioning.

As I told @macdis, you might as well include the whole LAN rather than specific LAN clients.

192.168.50.0/24 10.99.0.0/24 WAN

Also, I was playing around w/ 386.4, and I was NOT able to reproduce this problem. I tried quite a few times, but just couldn't trigger it. I'm wondering if perhaps Merlin actually did make a change to briefly delay the start of the OpenVPN clients in order to let the OpenVPN server get established first and avoid this "bug". I'm going to keep trying a bit more, just to make sure. It would be nice if that was the case.

P.S. This problem was also identified in the following thread as well, although I only offered the scripting solution in the current thread.

problem with connection between wan and device connected to vpn client

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...

www.snbforums.com

 

[Andame67]

Hi everyone on this topic,

I came here because I think it describes my problem but I'm not quite sure. My knowledge of routers and scripts is low but I do have patience to try things. I have an Asus RT-AX86sen that I have already equipped with the merlin software. I actually want to surf the internet safely from anywhere by setting up a VPN from anywhere and from my router to the internet via a VPN. It works independently of each other but not together. I also installed the script mentioned in this threat. I also can't find a log that records where things go wrong. At the times when I try to connect I don't see any logs being created. I hope someone can help me further. Thank you very much

 

[eibgrad]

UPDATE: v2.0.0 is now available.

I've updated the script. It's exactly the same as before in terms of how it works and behaves, but I've revamped how the files are created and managed.

You can use the following command to download and install it using my new installer.

curl -kLs bit.ly/merlin-installer|tr -d '\r'|sh -s kTThBV46

It will create two (2) files.

/jffs/scripts/merlin-ovpn-sync-routes.sh
/jffs/scripts/openvpn-event

openvpn-event is just a simple shell that calls the merlin* script.

I've been updating all my scripts in this way, so it's easier for someone to resolve conflicts when other scripts (whether from me or others) need to use the same event scripts. I was previously burying the meat and potatoes of my scripts in the event scripts, making that process too difficult. For the purposes of changing options, you just need to concern yourself w/ the merlin* file.

If you need to uninstall it, just delete those same files.

rm -f /jffs/scripts/merlin-ovpn-sync-routes.sh
rm -f /jffs/scripts/openvpn-event

FYI. According to Merlin, this problem will be fixed in the next release, thus eliminating the need for this fixup.

 

[Stephen Harrington]

FYI. According to Merlin, this problem will be fixed in the next release, thus eliminating the need for this fixup.

With today's 386.7_2 release, I notice release notes say:-

- FIXED: OpenVPN clients wouldn't get updated routing tables
         if an OpenVPN server was stopped/started while an
         OpenVPN client was connected

Has the need for your script now gone away @eibgrad ?

Or is that another issue and I'm way off target?

 

[eibgrad]

With today's 386.7_2 release, I notice release notes say:-

- FIXED: OpenVPN clients wouldn't get updated routing tables
         if an OpenVPN server was stopped/started while an
         OpenVPN client was connected

Has the need for your script now gone away @eibgrad ?

Or is that another issue and I'm way off target?

I mentioned this was being fixed in the next release only yesterday.

[SOLVED] OpenVPN server and Client not allowed at same time?

It seems to me that if it's not considered an issue to fix permanently in the firmware, then it can just be an option "Add [server] route to these clients:"

www.snbforums.com

Of course, until I've had a chance to verify it fixes it completely, I'll hold off on saying it's no longer needed. It certainly will continue to be needed by those that can't/won't update for some reason.

 

[Stephen Harrington]

Of course, until I've had a chance to verify it fixes it completely, I'll hold off on saying it's no longer needed.

Thanks @eibgrad , await your investigations with interest.
As always, thank you for your endeavours for our collective benefit, it's much appreciated.

 

[eibgrad]

Thanks @eibgrad , await your investigations with interest.
As always, thank you for your endeavours for our collective benefit, it's much appreciated.

Understand I did a *very* cursory review of the fix. One problem I have is I'm unable to reproduce the problem on bootup because my OpenVPN client *always* gets started after the OpenVPN server. The problem is the reverse, when the client gets started before the server.

But w/ that caveat, it does appear to be working. With the OpenVPN client ON before manually starting either OpenVPN server, I can see neither server's network interface (tun21 or tun22) is there, as expected. But as soon as I start either server, it gets added to the OpenVPN client's routing table (ovpnc1 in my case). Tried turning ON and OFF multiple times, but I couldn't break it.

But again, it was a brief check. I tested it maybe 10 times, and only w/ the one OpenVPN client.

So starting w/ 386.7_2, you should be able to eliminate my script.

 

[Stephen Harrington]

So starting w/ 386.7_2, you should be able to eliminate my script.

Thanks @eibgrad, I disabled openvpn-event (which only had your script call lines in it) soon after the upgrade to 386.7_2, will continue to monitor.