OpenVPN - Only works for a single user at a time.
-
Hi,
First time posting in the forum for a while but all of you guys have been a great help over the years.
I'm running OpenVPN with no user certs just radius and local auth with auto TLS. For some reason when a user is connected and a second user connects, the second user authenticates with their own username/ password fine and learns all the correct routes but cannot ping anything over the VPN.
The first user is still working fine with no issues but the second user is unable to use the VPN even though they are connected.
I've ticked random source ports and "Allow multiple concurrent connections from clients using the same Common Name" but still nothing.
Let me know if you need any more information than that.
Running 2.4.2-RELEASE (amd64) on hypervisor.
Thanks in advance.
-
Verify your tunnel network is not a /30 and that concurrent connections is set high enough. If that all checks out, post a sanitized config.
-
Thanks for the suggestion. Im running a /24 as per below and /30 is not selected.
Server Configuration:
Server mode - Remote Access (User Auth)
Backend for Authentication - Radius and Local Database
Protocol - UDP on IPv4 only
Device mode - tun - Layer3 Tunnel Mode
Interface - CARP Address
local port - 1194
TLS Configuration - Use a TLS key
TLS key Usage Mode - TLS Authentication
DH Parameter Length - 2048 bit
ECDH - Use Default
Encryption Algorithm - AES-256-CBC (256 bit key, 128 bit block)
Enable NCP - Unchecked
Auth digest algorithm - SHA256 (256-bit)
Hardware Crypto - No Hardware Crypto Acceleration
Certificate Depth - One (Client+Server)
IPv4 Tunnel Network - 192.168.10.0/24
IPv4 Local network(s) - 192.168.1.0/24,192.168.2.0/24,192.168.3.0/24,192.168.4.0/24,192.168.5.0/24
Compression - Adaptive LZO Compression [Legacy Style, comp-lzo adaptive]
Inter-client Communication - Allow communication between clients connected to this server
Duplicate Connection - Allow multiple concurrent connections from clients using the same Common Name
Dynamic IP - Allow connected clients to retain their connections if their IP address changes
Topology - Subnet – One IP address per client in a common subnet
DNS Default Domain - mydomain.co.uk
Block outside DNS - unchecked
Force DNS cache update - unchecked
NetBIOS enable - enabledClient Configuration:
dev tun
persist-tun
persist-key
cipher AES-256-CBC
ncp-disable
auth SHA256
tls-client
client
resolv-retry infinite
remote "FW CARP Address" 1194 udp
lport 0
auth-user-pass
ca FW01-UDP4-1194-ca.crt
tls-auth FW01-UDP4-1194-tls.key 1
remote-cert-tls server
comp-lzo adaptiveThanks for taking the time to help.
-
You didn't list the setting for 'Concurrent Connections' (Although you get a pretty descriptive error when you hit that).
Other than that, looks pretty normal. Anything logged on the server when the second client connects? -
You didn't list the setting for 'Concurrent Connections' (Although you get a pretty descriptive error when you hit that).
Other than that, looks pretty normal. Anything logged on the server when the second client connects?Sorry, Concurrent connections was set to 10 but I've now left it blank.
I can't see any errors from the server end that would suggest an issue but there is a lot in the logs for each step of the vpn forming. I can post a sterilised version of the logs if needed but both clients get the routes in their routing tables but only the first client connection can route the seconded says it's connected but cannot route across the VPN. I've even reversed the clients so that the other connects first but I get the same result.Thanks.
-
Sorry, Concurrent connections was set to 10 but I've now left it blank.
Not sure what it defaults to, I'd put it back to 10.
I don't see anything obviously wrong with the server side… Did you use the client export for the clients, or configure them manually? -
Okay, I've set it back to 10 connections.
I used the client export for all the current clients. Do you think it will help if I tried to configure them manually?
Thanks.
-
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 ovpns1Notice 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 ovpns3The 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 ovpns1I 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=0That 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 tableIf 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.210Then 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 ovpns1I 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 0Then 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.
