It's also been fixed in the repository for a while now: https://redmine.pfsense.org/issues/8391

Try this guide https://nguvu.org/pfsense/pfsense-inbound_vpn/ It has some useful tips.

https://www.speedguide.net/analyzer.php Here's where I get the values: 1397 MTU(now after testing tun-mtu values) 1357 MSS I currently have these advanced options set: fixmss; tun-mtu:1400 I was able to confirm these are functional after setting the MTU to 1300 and getting that result on the test above. but with 1400, it seems 1397 is the best I can do, which makes sense if the MSS of non-tunneled packets is 1460 (40bytes of headers) - another 40 bytes for encapsulated packets = 1420, so it seems there's about 23 bytes of OpenVPN headers for TLS/SSL authentication. I was just hoping to get as close to the 1420 I've seen in IPsec as possible. I'm not using IPSec because of the routing functionality. I set the tun-mtu to 1402 and the tested result still returns the above results with MTU 1397

Oh, thx for that plausible example. That makes sense ;)

https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting You will want to put the port forward on the OpenVPN assigned interface. You will want to be sure the rules on the OpenVPN interface group tab DO NOT match the port forwarded traffic. In fact, if this is your only OpvnVPN client, just delete/disable all rules on the OpenVPN tab.

It is just the way OpenVPN works. That route gets traffic for the /24 into OpenVPN. From there OpenVPN does the right thing.

@ashima: Hi, That is possible if you are having site-2-site openvpn connection. Then all the systems from Client A side can access 192.168.20.x series and vice versa. As far as I can understand from your post  is that you are running windows based openvpn client software  on individual systems on Client A. If that is the case then I guess you will  not able to access systems on Client A side from 192.168.20.x. I suggest to put up a device (may be another pfsense device) at Client A and then the two devices can make a openvpn connection. Then all the devices from either side should be able to talk to each other. regards, Ashima Thanks to all, following the Ashima suggestion I solved the problem, I just bought a simple router board  Mikrotik RB260GS and make the connection  site to site open VPN, So now is solved. Thanks to all for your cooperation, all the best. Gully

I have worked around this situation by just using the VPN server's IP address instead of its hostname in the VPN client config.

Apologies for the delayed response. I have to walk away as this was doing my head in. It can't be this hard… I have a VPN tunnel established between server and client1 (10.0.8.1 & 10.0.8.2) Both server & client1 have openVPN fw rules allowing full access. Server LAN can ping 10.0.8.1 & 10.0.8.2 Server pfSense can ping 10.0.8.1 & 10.0.8.2 Client1 LAN can only ping 10.0.8.2 Client1 pfSense can ping 10.0.8.1 & 10.0.8.2 Does this sound correct or does this indicate a problem?

Thank you for the detailed response, I will give it a try. Greg Edit:  I followed your suggestion and I have hosts going via the LA Server for particular domains.  However I have no access to any other websites/domains except those that go via the LA Server.  What could I have done wrong? Thanks, Greg Edit2: Deleted all my changes and started again, now it works just fine.

Are the certificates+keys password protected? If not, you can't import them without removing that password. That said, you do not need to import user certificates to use them. They won't be usable with the export package, but they are still valid for VPN Access so long as they validate against the CA as they should, and provided they are not on an active CRL.

@deepak11: Hi guys, I'm also having the same problem, and also I tried adding push route in "Advanced Configuration". its not working. any other suggessions ? deepak11, this is a 4.5 year old thread, you should start a new thread with your specific details in it, so we can offer targeted troubleshooting. At a high level, two things are needed: On site A's remote access config, push a route to site B's LAN to your clients On Site B's site-to-site config, add a return route to site A's remote access tunnel network This can all be done in the GUI now

Thanks!, I found all the certificates including the CA cert and private key. Just to add some information, this post https://forum.pfsense.org/index.php?topic=32372.0 help me get the string of this certificates from the base64 encoded xml fields.

@jimp: @iesjg.tic: Same problem here. Set up two instances with the same certs (for client access, not site-to-site) and only the first one appears in the dropdown. Reinstalled the client export package, same thing, only the first one shows Any ideas? Check the mode, as mentioned a few posts above. If it does not show in the list, it must not be set to a remote access mode. You're right! Just set "Remote Access (SSL/TLS)" server mode and showed up! Thanks!!

Thank you both so much for the clues!  I edited the existing rule created by the wizard on WAN, changing to protocol from "any" to "tcp" and that fixed it up. Really appreciate the help.

Found it!  I a Zxyel Zywall 110 and I forgot that I needed to add a dedicated routing setup after setting up the new IPSec connection. Thanks!

The thing is, it works on the Network 1; and route on pfsense is here, and route is on computer too, but don't work on OpenVPN connection [image: Capture.png] [image: Capture2.png]

Yep the client-connect script sounds ideal, need to test it on test unit to see what variables you can see will revert back.

Okay, well it sounds like you're set.  Policy routing is just using firewall rules to assign certain traffic to certain gateways and other traffic to other gateways (at least that's my high level understanding of it).  The alternative would be to be to assign traffic to gateways via static routes.  In any case, if you're set up with VLANs I trust you know what you're doing :)