@Gertjan It was a real issue and it's this is the Snort rules that generated it spotted it, I think that because it is a home network the bad guys assumed they could get away with it and pfSense plus stopped it cold and gave me the logs to report them. I have it on the WAN side the rules below. # === VPN SECURITY (OpenVPN UDP 1194) === # NOTE: Port corrected from 1192 to 1194 to match actual firewall # VPN connection from non-Approved source alert udp !approved source any -> MY IP1194 (msg:"CRITICAL: VPN Connection from Non-Approved Source"; classtype:policy-violation; priority:1; sid:1000010; rev:2;) # VPN brute force from MetroPCS alert udp approved source any -> MY IP1194 (msg:"OpenVPN Brute Force from MetroPCS"; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-admin; sid:1000011; rev:2;) # VPN connection flood (DoS) alert udp !Approved source any -> My IP 1194 (msg:"OpenVPN Connection Flood"; threshold:type threshold, track by_src, count 50, seconds 10; classtype:attempted-dos; sid:1000012; rev:2;) # OpenVPN malformed packet alert udp any any -> My IP 1194 (msg:"Malformed OpenVPN Packet"; dsize:<14; classtype:protocol-command-decode; sid:1000013; rev:2;) I reported it to IC3 and someone actually called me said it was really good stuff that I had, that it is a big problem in our area the last 8 or so months I think he said. This firewall caught something and it contributed to local cyber security. After he called, I have not seen as many of them anymore also. I also reported it to Digital Ocean and they responded to my report and thanked me for it. I have never had someone call me about a report before. The data was the combination of how many attempts and what was occurring they must have seen it before, maybe if you guys see vpn attempts from them we should start to report at least the VPNs that is like breaking and entering its no longer scans at that point. I feel like we see so much noise that when we start to see something that is real it get questioned, I was even thinking it was nothing, but they kept doing it.

@Lagan said in OpenVPN Client Specific Overrides ot updated until server restarted: I would like the new override to take effect when I restart the client. Hummm. It's possible that a save on the "Client Specific Overrides" page doesn't restart the OpenVPN server - I doesn't seem to do that. Maybe it isn't needed, as the server has a setting : client-config-dir /var/etc/openvpn/server1/csc/ that tells the server to look into that folder for client special settings, the "Client Specific Overrides". Anyway, I did restart the server, then connected the client and it got the '.30' IP.

@nattygreg Thanks I have attempted many trail and error tests, another one that gave me speed boosts was changing these settings. Screenshot 2025-03-03 at 21.50.05.png

@Gertjan So I used both tcpdump and radsniff to look at packet traces, but I can't see any issues. In both cases (working and non-working) the radius server sends back an Access-Accept message with the same set of fields.

@Draco By any chance you upgraded the pfsense (and or openvpn package) recently ? I got 'similar issue' that left me baffled till this day see here , maybe it is similar with what you experiencing.

Problem 2 fixed by adding route to 192.168.5.0/24 on Mikrotik side

@kstlan02 First off, it's not wise to use public IP ranges in the local network, even for docker. Then I'm wondering, why don't you run the OpenVPN server on pfSense. Do I have to do the port forwarding from the WAN to the LAN or do I have to do it from the WAN to the Docker container that is running OpenVPN? "LAN address" is the wrong destination here for sure. This is an IP assigned to pfSense itself. Hence forwarding to it, is not that, what you want. The question is then, how can pfSense reach the container? I'd expect, that the container gets its traffic forwarded inside the VM. But don't know, how you did configure it. So you have to forward the OpenVPN traffic either to the VM address or to the container IP. In the latter case, you would need to add a static route for it on pfSense of course.

Hey, In here I've decribed my work on this topic :) https://forum.netgate.com/topic/189447/openvpn-ssl-tls-user-auth-over-ldap/3

@jimp I tried but unfortunately it didn't work, because the User Certificate that I use for export the OpenVPN Client have the same CA that the server certificate (I think). The final solution was to reinstall all OpenVPN clients on all devices, hard work but at least all users continue to work! Thanks for the support

@kprovost The speed difference is substantial with only having one enabled so much so I would say this would need a Redmine to only allow one to be selected at a time. Anyone else agree?

@JonathanLee Thanks this fixed worked for me. My iPhone would not connect without it.

@Pablomdli said in OpenVPN site to site not working both ways: The only weird things is that it gives the ip 10.0.8.0 to de office#2 openvpn client So I'd suspect, that you stated this IP in the CSO. You should enter an IP out of the tunnel network there, but it have to be one from the second upwards.

@cezar_a your welcome

Trying to find a solution to this as well. It doesn't seem OpenVPN has an option to forward headers which basically makes it impossible to use openvpn as the primary on port 443 if you need to see client IP addresses on haproxy.. As an alternative, I wondered if it might make sense to set haproxy listening on 443 and OpenVPN as a backend on a different port. Has anyone tried this yet? Does this cause double encryption (slow down the connection too much)? Here is an example of one guy who claims to have got it working: https://discourse.haproxy.org/t/haproxy-with-openvpn-over-tcp-443-on-pfsense/4731/2 EDIT It looks like he create a TCP frontend on 443 with a default backend going to OpenVPN:TCP:1194 and an acl that checks for SSL and sends SSL traffic to an HTTPS Backend set to localhost:9443. Then he configured localhost:9443 as a Frontend that handles the forwarded Web Traffic. That looks like it should work, but It's a bit too complicated for me to test on my live server right now and I don't have a lab setup. Happy to help anyone else who might have a lab environment setup for testing.

I could certainly image that the faster you push traffic the more is lost, though not necessarily as a percentage. Do you see the same when connected to other servers? Is that server in London far from you, is the latency high? Steve