@DominikHoffmann Since you can reproduce it I'd create a bug report at redmine.pfsense.org.

edit: Apr 26 11:17:34 openvpn 83673 do_ifconfig, ipv4=1, ipv6=0 Apr 26 11:17:34 openvpn 83673 /sbin/ifconfig ovpns4 172.16.10.1 172.16.10.2 mtu 1500 netmask 255.255.255.255 up Apr 26 11:17:34 openvpn 83673 /usr/local/sbin/ovpn-linkup ovpns4 1500 0 172.16.10.1 172.16.10.2 init Apr 26 11:17:34 openvpn 83673 /sbin/route add -net 10.4.0.0 172.16.10.2 255.255.0.0 Apr 26 11:17:34 openvpn 83673 /sbin/route add -net 172.16.20.0 172.16.10.2 255.255.255.0 Apr 26 11:17:34 openvpn 83673 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1800 tailroom:568 ET:32 ] Apr 26 11:17:34 openvpn 83673 Socket Buffers: R=[42080->524288] S=[57344->524288] Apr 26 11:17:34 openvpn 83673 UDPv4 link local (bound): [AF_INET]175.144.139.191:1120 Apr 26 11:17:34 openvpn 83673 UDPv4 link remote: [AF_UNSPEC] This is log from Server. Is there any indicator showing something wrong or its perfectly fine? VPN has been down for awhile when using openvpn after update on pfsense. anyone care to help?

@James92 It's pretty hard to tell you, what's wrong there, when only seeing two rows extracted from the log. Clear the OpenVPN log. Go into the server settings and set the log verbosity level to 4. Then try to connect from a client. Post the whole OpenVPN log after. You can obscure public IPs of course.

I want to force the client to use its own internet gateway. In my scenario, the client must definitely use its own internet. Some clients can send all traffic over VPN and the internet can be accessed through the VPN server's internet. I prevent this situation with security rules, but this time the internet cannot be accessed in any way. Even if routing is done to access the internet via VPN, my VPN server must not allow this and force it to use its own gateway. How do I do this?

@lifeboy Does the windows client machine have other network adapters such as vmware virtual adapters ?

@guillaume14 I made some tests with 2 pfsense box on the remote site: the first one (192.168.10.254) is the default gateway for the remote site computers (192.168.10.0/24) the second one (192.168.10.129) has only one interface (WAN) with 192.168.10.254 as a the default gateway and the OpenVPN client instance to the OpenVPN HQ instance If i add a route to the HQ site (192.168.14.0/24) on the first pfSense box using 192.168.10.129 as the gateway i cant access devices on the remote site (copier web interface for instance) from a computer in the HQ site but i can do a tracert to the same copier. Any clue ? Thanks

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

Thanks @viragomann that works perfect

A reboot fixed it, but would be interesting what can cause this issue.

The problem still exists in 2.7. If during the OpenVPN client connection the interface, specified in client's config, is down, the connection happens through another gateway (which could be a metered backup connection for example). This is a major issue in my opinion. UPD: "Do not create rules when gateway is down" option is checked BTW.

@mathais said in pfsense+ NordVPN slow speed: What do you think about going to Torrent download sites and downloading Torrents without a VPN? No need to use a VPN to access a torrent access point, right ? Also, downloading something from a torrent, and "secure my network infrastructure" is imho somewhat contradictory. @mathais said in pfsense+ NordVPN slow speed: In France, we have HADOPI which tracks downloads. So the VPN is useless? I know. I've dealt ones with them. Received a first warning, and I knew it was coming as I discovered earlier that a night auditor was using one of the PC's at work (hotel !) to download 'Disney' movies during his working hours, night time. He told me : "don't worry, I only download "VO" (original, English spoken language - no french subtitles) movies so no risk". Well ... he was wrong. I received a message from HADO and he was fired for this. He still didn't got the message afterwards, and had the great pleasure to meeting the "Disney lawyers" in court. That didn't went well at all. On the other hand : I do something that is considered totally insane : I share 'my' (work) internet connection with an entire hotel == a whole bunch of people unknown to me, also known as my "clients". They can do whatever they want with the connection I offer. If things go downhill, no problem, the owner (the one that subscribed to the internet connection" will do some jail time or has to pay the fine. Great. Basically, you can share your internet connection with everybody as long as you agree to assume all consequences - no exceptions. But I discovered something : during my 20+ year of internet sharing, and ten (hundreds) of hotel clients later, I never received another HADOPI message again. I do use pfBockerng on my hotel's captive portal access to block the most obvious IP and DNSBL destinations. That seems to do the trick, I'm not sure. Maybe people stopped doing illicit things while using a public hotel network ? Or : right after connecting to the portal : they active their VPN.

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