I solved it by making a gateway on a dynamic IP and setup a rule in my LAN that is connected to the gateway to transfer all traffic, here's my setup: Enable your OpenVPN interface (you can rename it) [image: 6f27b79f1bd849d3b4a11a54ae88f65f.png] Create a gateway with a dynamic IP, I set my monitoring IP to my VPN's tunnel IP [image: d818d364644e4b4cb9e2f556a71c4174.png] Go to VPN -> OpenVPN and go to your server's settings and this line [image: e9a9b83ec19c4569bf4e3a5e55a2dddd.png] Go to Firewall -> Rules -> LAN and create this rule (You'll need to click show advanced settings) [image: 7dcf9b69c2c24e5ba2e0887e33b97941.png] Then you can port forward to that tunneled IP you want to host the server on Firewall -> NAT [image: 73aaad3793a141c6a300dfedf3b758ef.png] Last you forward is in Firewall -> Rules -> Opt1 (Destination is the tunneled IP) [image: 06447c7b2d94439e9916da9c56743c7a.png] Sorry if I missed anything, I hope this helps though or at least point people in the right direction. The goal was to make the server owner who can't open his ports just login to my VPN & then people connect through my IP and they'll join his server, without needing to connect to the VPN themselves.

I fixed this problem.I wasnt related to pfSense at all.I was wondering how can I set MTU 1492 only for OpenVPN.I know how to do it using advanced options but I was wondering I need to change it in the physical interface used for connection.Thank you.

I think I may have just had one of those answered your own question after asking it moments. In following that guide and others, I was using the net30 option but I see that is deprecated now and the default is set to use a subnet topology. Looking at my settings, it seems that in the upgrade my config changed to the new default which I assume would explain it breaking. Since then I seem to have confused myself and have ended up with a net30 config but not with that option selected, so the VPN probably has no idea what is going on. I think I'll sleep on it and take another look in the morning, hopefully I've understood that correctly and can fix it. Please let me know if I'm still confused though, in case I'm just going down another wrong track. Thanks.

but your hosts are not using dns through the tunnel they are using pfsense.  Pfsense is not sending the resolver traffic through the tunnel is just sending it out your wan. Yes, I know and this is what I want to change. I want the VPN Clients (and only the VPN clients) to send their DNS queries down the tunnel to the VPN provider. as for IPv6, I only want to prevent VPN clients, as defined by their alias, from getting or using IPv6.

Came across this looking after finding that the VPN client (OPENVPN ios) stayed connected after I disconnected the user connection from status>OpenVPN by hitting the X next to their connection. I expected the behavior the original post was describing and was puzzled why it not only showed on the client that it was still connected, but also why after attempting to access a resource located behind the VPN connection that it connected back up and worked. Rather than disabling account or trying to change the timeout/reconnect options, I found the best way to have this control to disconnect a session is to set up authentication to another directory (Ldap) and filter approval based upon group membership (memberOf). This way one can remove the account from the LDAP group, then click the X to close the client vpn session from the server side. The client then tries to (automatically) reconnect and fails based on authentication. I found that this is the only clean way to have administrative control over the client vpn session apart from disabling the entire user account or disabling the VPN server itself. Thanks, Brian

It's highly unlikely to be a firewall rule problem. If it's getting that far, it's passing through. Check the OpenVPN logs on the client and server for more clues.

No there is no problem with 2.3.1, I use vpn on it every single day, multiple times a day from multiple devices.  I can not recall there ever being any issue with openvpn on any build.. I have never had any issues even with upgrades multiple times all the 2.x and 2.x.x builds and now 2.3 no issues.  Openvpn works clickity clickity.. run the wizard, grab the config and connect it really is clickity clickity if it takes you more than 2 minutes to setup a openvpn connection into pfsense your doing something at a basic level wrong.  Like not going to the right IP.  Not using the wizard and trying to use a user cert vs a server cert.  Using a port that is not open inbound to pfsense either from where your at or by your isp or pfsense is behind a nat at your location and you didn't forward the right port, etc. The wizard even creates the firewall rule for you.  But if you had created some rules on your wan that would block before it gets to your open that could cause problems.  Using something like snort might cause you grief if not configured correctly, or pfblock if letting it create rules and those are blocking, or even using its aliases and you misuse them in the rules, etc. Or maybe you didn't answer the questions correctly on the wizard for what your wanting to do, maybe your local networks or remote networks are wrong or maybe your at a location where you have the same IP as the network behind pfsense, etc.  There are for sure lots and lots of things that could be misconfigured or cause problems but out of the block its really click click openvpn server up and running. Without details its impossible for anyone to help you spot the problem.  But I can tell you for sure trying to connect to a rfc1918 from outside pfsense on the internet somewhere is going to FAIL 100% for sure.. Not sure what your doing different if your saying its working on 2.2.x but not 2.3  But accessing a 192.168 address from the internet is never ever ever going to work.

This is probably OpenVPN`s problem. There was a discussion about this on the OpenVPN mailing list some time ago. Maybe take a look there in the lists archive? Groet

Have you tried doing those same http downloads on the server itself with wget or curl and see how it performs?

No. Changing the IPsec tunnel to accommodate the additional subnet is the best practice. If your OpenVPN subnet can be summarized into a larger network with your LAN (e.g. x.x.0.0/24 and x.x.0.1/24) then IPsec could just use a wider mask on your side (e.g. x.x.0.0/23). Check a subnet calculator to be sure.

Bump ! Sorry team for bumping this up… But, do need a solution for this. Will appreciate any help/pointers/direction of investigation. Alok

https://redmine.pfsense.org/issues/3478 It would be nice to see, but the way the page was designed (before my time, even), it makes that very difficult to support.

well, pfSense probably hasn't created NAT rules for the vpn subnet. you could manually add them or you could assign an interface to your openvpn: i believe pfSense will add NAT automagically then (don't shoot me if i'm mistaken)

Opened bug ticket here. https://redmine.pfsense.org/issues/6580

found the problem: Jul 5 23:30:51 openvpn 19584 OpenVPN 2.3.11 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on May 16 2016 Jul 5 23:30:51 openvpn 19584 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09 Jul 5 23:30:51 openvpn 19913 Could not retrieve default gateway from route socket:: No such process (errno=3) Jul 5 23:30:51 openvpn 19913 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts Jul 5 23:30:51 openvpn 19913 Initializing OpenSSL support for engine 'rdrand' Jul 5 23:30:51 openvpn 19913 Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Jul 5 23:30:51 openvpn 19913 TUN/TAP device ovpns1 exists previously, keep at program end Jul 5 23:30:51 openvpn 19913 TUN/TAP device /dev/tun1 opened Jul 5 23:30:51 openvpn 19913 ioctl(TUNSIFMODE): Device busy: Device busy (errno=16) Jul 5 23:30:51 openvpn 19913 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Jul 5 23:30:51 openvpn 19913 /sbin/ifconfig ovpns1 10.20.30.1 10.20.30.2 mtu 1500 netmask 255.255.255.0 up Jul 5 23:30:51 openvpn 19913 /usr/local/sbin/ovpn-linkup ovpns1 1500 1560 10.20.30.1 255.255.255.0 init Jul 5 23:30:51 openvpn 19913 Listening for incoming TCP connection on [AF_INET]86.126.1.236:1194 Jul 5 23:30:51 openvpn 19913 TCPv4_SERVER link local (bound): [AF_INET]86.126.1.236:1194 Jul 5 23:30:51 openvpn 19913 TCPv4_SERVER link remote: [undef] Jul 5 23:30:51 openvpn 19913 Initialization Sequence Completed Not able to get default gw. How to solve it now?

Darn, I think I finally found the culprit: I had an old IPSec config on those boxes (preferred VPN solution but never got it work reliably) which was inactive but not disabled. It seems as if this messes up some internal routing (not reflected by the routing table). It also seems that this is a regression in 2.3.? since 2.2.6 still doesn't have this problem! IIRC, the enable/disable implementation of IPSec changed in 2.3 so that would explain it. That was a mean one… Cheers

Hi All, Thanks to Nastov's problem description and Probie's response to that, i managed to get the issue fixed for my Customer mgmt-oVPN network. Things i had to change in comparison to the former V2.2.6 setup: General: Set topology to "Subnet", on both the server (hub) side and client (spoke) side, wherever i was not set to Subnet already. Server side: In the OpenVPN server config fill in the tunnel network as a /24 network (in Probie's example it would be: 10.9.9.0/24) In the Client Specific Override's i cleared the tunnel-network (<blank>) and left the ifconfig-push as it was before, including the dash. Client side: In the OpenVPN client config i also cleared the tunnel-network to <blank>. In this way, every client got it's unique tunnel IP-address (/24-/32) again and i was able to get the right traffic on the right VPN-tunnel for each spoke. Hooray!  8)</blank></blank>

It's a little unclear as to what type of scenario you're describing. Do you mean a typical "Road-Warrior" setup - a Remote Access OpenVPN server allowing guests on phones, laptops, etc. to connect remotely? If so, the server has one port that handles all of the clients connecting.  It typically can handle 30-100+ clients simultaneously (depending on your hardware) all through that one port.  What differentiates all the clients is they should each have their own certificate that proves their authenticity to the OpenVPN server. So you setup one OpenVPN server, and 25 certificates for your 25 users, not 25 ports.