OpenVPN - Only works for a single user at a time.
-
I used the client export for all the current clients. Do you think it will help if I tried to configure them manually?
No, It's usually best to use the client export.
At this point, you're going to have to dig in the logs. I haven't seen this problem before. -
Hi, Thanks for your help so far.
I've checked the logs from two users. The first one seems to have a lot more entries than the second. Not sure if this is because it's the first connection to the server so processes have to start that weren't running prior to the connection?
Take a look at the attached logs and see if you can make any thing of them.
Thanks!!
[OpenVPN - Logs.zip](/public/imported_attachments/1/OpenVPN - Logs.zip)
-
Mine generally look like client2 connects on the server side. Something is happening after client1 connects- it runs the linkup script and goes wrong- there's a failed route add and process sigterms. Check the .conf file in /var/etc/openvpn/ and look at the logged warnings.
-
So, I went through the logs last night and found that the route was being added to the second client however it isn't passing traffic.
It shows that there was an error in the log so I simplified the setup and just added a /32 route and got rid of all of the other subnets. This still didn't work.
I then changed the VPN so it was default route for all client traffic. This worked for a single user but got the same error with the second user.
I can create another firewall with OpenVPN to simplify the setup even further in an attempt to test in a clean environment. I'll be doing this today at some point.
-
Why do your logs say its 2026 either Jan 2 or Feb 1st?
-
Well spotted. I checked the time and it is correct. Looks like excel didn't like the time and date format when I copied and pasted from pfsense.
Thanks.
-
Your 2nd user log doesn't seem to finish..
And these are actually remote users right? Your not trying to test this via some local box?
2nd user is any other user after the 1st connection, or you testing from the same user machine? They are running gui as admin? To be able to add the routes… What is the clients log look like?
-
Okay, so I build another firewall just to run OpenVPN and ….. IT WORKS!!
The firewall cluster I have has a lot of routes and interfaces so I though it best to simplify the responsibilities and just add another publicly available firewall with just VPN access in the same local subnet as the cluster. It's locked down so you can only access the admin from the LAN.
I can now see all the required subnets and multiple users can log in at the same time. The only issue is that I can't ping the local subnet of the firewall but seeing as this is only a /29 I'm not that worried.
Thanks for all your help guys and I realise that I haven't fixed the problem but found a work around. Sorry to anyone who has the same problem but I think it is something to do with the amount of routing and NATing the firewall is doing.
Thanks.
-
We have this same problem, which seems to be a routing issue/bug on the pfsense end.
We have 2 vpns defined, one with a tunnel network of x.x.x.208/29 and the other with x.x.x.216/29; when connecting on the first vpn if you get address .210 assigned everything will work, but if you get .211 - .213 it connects but does not pass traffic both directions; the second vpn is currently unused.
Just now another user was connected with .210 and working; as the second vpn is unused, noone was on .218 or any other address (confirmed). The routing table on pfsense showed:
x.x.x.208/29 x.x.x.177 UGS igb0.8 x.x.x.209 link#22 UHS lo0 x.x.x.210 link#22 UH ovpns3 x.x.x.216/29 x.x.x.177 UGS igb0.8 x.x.x.217 link#23 UHS lo0 x.x.x.218 link#23 UH ovpns1
Notice the host route to ovpns3 interface for the working .210 address (also for the unassigned/unused .218 address).
I then connected to the first vpn and received the .212 address, checked the routing table on pfsense and found it had not changed, and my vpn traffic did not work (eg. simple ping test).
I disconnected my vpn, and knowing I will be assigned the .213 address next time I ran this command on pfsense cli:
route add -host 64.187.64.213 -interface ovpns3
The routing table now shows:
x.x.x.208/29 x.x.x.177 UGS igb0.8 x.x.x.209 link#22 UHS lo0 x.x.x.210 link#22 UH ovpns3 x.x.x.213 ovpns3 UHS ovpns3 x.x.x.216/29 x.x.x.177 UGS igb0.8 x.x.x.217 link#23 UHS lo0 x.x.x.218 link#23 UH ovpns1
I connect on the vpn again, received .213 address as anticipated, and my vpn traffic works this time.
I turned up debugging and see this in the log:
openvpn 3191 /usr/local/sbin/ovpn-linkup ovpns3 1500 1621 x.x.x.209 255.255.255.248 init Mar 14 11:21:01 openvpn 3191 ERROR: FreeBSD route add command failed: external program exited with error status: 1 Mar 14 11:21:01 openvpn 3191 /sbin/route add -net x.x.x.208 x.x.x.210 255.255.255.248 Mar 14 11:21:01 openvpn 3191 /sbin/ifconfig ovpns3 x.x.x.209 x.x.x.210 mtu 1500 netmask 255.255.255.248 up Mar 14 11:21:01 openvpn 3191 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
That looks like it's trying to add a /29 subnet route to the .210 address, which is probably what would make it work. When I run that route command manually I get:
/sbin/route add -net x.x.x.208 x.x.x.210 255.255.255.248 add net x.x.x.208: gateway x.x.x.210 fib 0: route already in table
If instead I run:
/sbin/route change -net x.x.x.208 x.x.x.210 255.255.255.248 change net x.x.x.208: gateway x.x.x.210
Then the routing table shows this, and all my vpn connections (to the first vpn work correctly:
x.x.x.208/29 x.x.x.210 UGS ovpns3 x.x.x.209 link#22 UHS lo0 x.x.x.210 link#22 UH ovpns3 x.x.x.216/29 x.x.x.177 UGS igb0.8 x.x.x.217 link#23 UHS lo0 x.x.x.218 link#23 UH ovpns1
I don't know what all the relevant settings are, but I'm on pfsense 2.4.4-RELEASE-p2 (amd64), using 'tun - Layer 3 Tunnel Mode', 'Redirect IPv4 Gateway' is unchecked, 'Concurrent connections' is 5, 'Inter-client communication' is unchecked, 'Duplicate Connection' is checked, 'Dynamic IP' is checked, 'Topology' is subnet, and 'Gateway creation' is 'IPv4 only'.
As a workaround I created this script as /usr/local/sbin/local-learn-address.sh:
#!/bin/sh # # local-learn-address.sh # # workaround for pfsense routing bug with openvpn, # called as learn-address script # /sbin/route show $ifconfig_pool_remote_ip | /usr/bin/grep -q "interface: $dev" if [ $? != 0 ] then /sbin/route add -host $ifconfig_pool_remote_ip -interface $dev -nostatic fi exit 0
Then added 'learn-address /usr/local/sbin/local-learn-address.sh;' to my openvpn custom options.
I don't find any issue in the bugtracker for this. (Also my testing shows another bug, where only 4 ip addrs are ever assigned to clients (.210 - .213) despite specifying 5 connections, the 5th (.214) is never used. I Don't find a but report for that either offhand.)
-
@jnorell I know it's been a little while since you put this together, but i'm trying to get this working on my local appliance and ran into some weird behavior so I was wondering if you could help me understand where you obtained those variables used in your script?
-
@handleric said in OpenVPN - Only works for a single user at a time.:
you could help me understand where you obtained those variables used in your script?
Available variables are listed under the 'Environment Variables' heading in the openvpn man page. If it's easier, you could just dump the environment from your script to a tmp file and see what you've got to work with. (
env > /tmp/my-script-vars.txt
) -
@jnorell Thanks for the troubleshooting for this. I'm having the same exact problem with openVPN on pfSense 2.4.4-release-p3. Have you been able to test if this is resolved with 2.4.5? Also have you had any trouble with removing routes after a user is disconnected?
-
@khuram said in OpenVPN - Only works for a single user at a time.:
Have you been able to test if this is resolved with 2.4.5?
I haven't had any problem with it since it was put in place, but no, it looks like we're on 2.4.4-RELEASE-p3. I'll update and see if there are any issues.
@khuram said in OpenVPN - Only works for a single user at a time.:
Also have you had any trouble with removing routes after a user is disconnected?
No, none known. We don't have a large number of users (eg. 3 connected right now), but I generally get reports when there are problems that persist, and have had none.
-
@khuram said in OpenVPN - Only works for a single user at a time.:
Have you been able to test if this is resolved with 2.4.5?
I did test this system some more, and no, the issue is not fixed in 2.4.5; once I remove this workaround, only the first openvpn client (.210 addr) has a working connection.
I'll note that I tested openvpn on another 2.4.5 system and did have 2 working clients at the same time. There are quite a few differences in the two setups, but I suspect most relevant were the second system assigned a private ip range to the openvpn clients and uses nat, and is a single system, and both the working clients were behind the same remote ip (using cell phone hotspot), whereas the first system (above) assigns public ip's, is a failover pair, and clients are all on different remote ip's).
-
@khuram said in OpenVPN - Only works for a single user at a time.:
Also have you had any trouble with removing routes after a user is disconnected?
With this workaround in place, the routes appear to not be removed. Eg. after I just received a .211 address, I see:
x.x.x.208/29 x.x.x.177 UGS igb0.8 x.x.x.209 link#21 UHS lo0 x.x.x.210 link#21 UH ovpns3 x.x.x.211 ovpns3 UH ovpns3 x.x.x.216/29 x.x.x.177 UGS igb0.8 x.x.x.217 link#22 UHS lo0 x.x.x.218 link#22 UH ovpns1
That does not seem to create an issue for us.