Thanks for the explanation, Clients don't use ns-cert-type server but they have remote-cert-tls server. As OpenVPN server is working just fine even with this "Server: No" certificate, I'll keep it but in the mean time I'm a bit less ignorant now :)

Fixed or worked around.. They are completely different ;) Source natting would not be a fix to me..  That would be a work around.  To me the proper fix for your issues would be correctly setting the firewall rules on your devices to accept the traffic you want to accept.  Or make the choice that devices on network X behind pfsense do not need a software firewall because they trust all the devices on their same network, and devices that are hostile or not trusted are firewall at pfsense. To a nas.  it should have a gateway set if that was your issue.  Or if firewall - same thing goes.  Tricking something into thinking a connection is from the same local lan as it to get around firewall rules and or lack of gateway is a work around if you ask me. Either way glad I could be of help, but if you went the source nat method.  I would would evaluate if that is the best long term fix vs stop gap workaround until proper setup can be used, etc.

@semprini: I was under the impression that username + password + cert = successful login, and username + password + wrong-cert = failed login. Got to the server settings and check "Strict User-CN Matching". Then it should behave the way you want.

As Jimp suggested Im gonna post logs and related data on the thread I previouosly opened for this: https://forum.pfsense.org/index.php?topic=116670.0 Thx

Good catch on the 172.168 helper!!!  I missed that.

@marvosa: … per your screen shots... you currently do not have any clients to export.  You will see client configs available for export after you've added users to PFsense (System -> User Manager -> Users). [image: 5.png] [image: 5.png_thumb]

Hi viragomann, Thanks for your reply. It works, there are no DNS leaks anymore :) !

OK, my bad. What I am trying to do is set up openVPN for access from iPhone (ios) I had it working but with a bunch of questionable errors in the log. I had created my .conf by hand.  I recently read here that the wizard needed to be used to make sure all was properly done. So started over and blew it by choosing peer/peer.  Lesson - don't do this stuff late at night.  :P My mistake was: setting up server for peer/peer tls instead of remote tls. creating a client, not necessary cause export creates it.  Changing server to 'remote tls' and going directly to client export gives me the missing part of the puzzle. Thanks for pointing me in the right direction.

It looks like I might be having a more basic problem.  Attempting to create a basic interface bridge is failing.  Posted on the General category to get help on that. Did you have a procedure you followed for creating the VPN bridge?

I think the bottom line is that for some use cases we need to be able to manage groups at the VPN server level. The preferred solution is to use LDAP but LDAP is not a accessible for everyone. Having a LDAP to manage VPN permission is for a lot of us overkill. It adds complexity, cost, single point of failure etc … A simple workaround would be to install (package) a local LDAP instance on as a Local LDAP. Ideally this would be sync with the backup instance as well.

Yeah. Outbound NAT on WAN. Good deal.

A server certificate has this attribute: Netscape Cert Type:                 SSL Server The following extensions are non standard, Netscape specific and largely obsolete. Their use in new applications is discouraged. idk. See Also: man x509v3_config I am not 100% sure exactly what needs that to be present, but it's not pfSense. Maybe strongswan and openvpn. You will probably find it easier to keep the certificates on pfSense so you can use the client export utility but there is no requirement to do so. You do have to have the CA certificate installed on the firewall so openvpn can validate client certificates against it but you don't need the private key there unless you are going to generate/sign client certificates there. You will need to import the certificate and key parts as the server cert but they do not have to be generated on pfSense.

Fixed it, I had an old firewall rule from something I was experimenting with that was messing it all up. Works great as you suggested I configure it, thank you! If anyone's interested I was able to figure out the DNS leak issue and patch it by reading this thread: https://forum.pfsense.org/index.php?topic=66305.15

Pfsense 2.3.2-p1

@jimp: It shouldn't matter if you stopped/killed it. When you delete a client it is automatically stopped and removed. So nothing shows up at all under VPN > OpenVPN on the Clients tab now? There has to be something there or the status page couldn't see an entry to print in that way. VPN > OpenVPN > Clients is compleltly empyt no clients there. I will take a closer look when I get home.

Thanks for the support! After your advice routing was ok, but clients that are behind pfsense respond only to the ping… no http, no ssh, nothing!!!! I thought it was some sort of firewall rule, but the problem was that pfsense is on a VM (kvm on very old proxmox1.9): solved with this https://doc.pfsense.org/index.php/VirtIO_Driver_Support Tanks

@vtulin: @jimp: On 2.3.3 we now have an option "No Preference and Adaptive Compression Disabled" which helps when dealing with picky clients. Which will remove accurance of this option in config? Thank you for response. When this option is selected, "comp-lzo" is not in the config, and it adds "comp-noadapt" to disable adaptive compression. OpenVPN can be picky in how the client and server interact across versions and when LZO is not compiled in. If you have no compression options in the configuration at all, it still enables it with adaptive compression because that's the current OpenVPN default (it wasn't always). And if you use "comp-lzo no" the far side won't understand that if it does not have LZO compiled in.

Yes, correct. The outbound NAT translate the packets source IP from origin VPN clients address to the FW2s LAN IP. So when the packets reach your LAN host, it seems the come from FW2 and it will response to FW2 where the destination address of the packets is translated to the VPN clients IP. We've discussed this yesterday here: https://forum.pfsense.org/index.php?topic=120328.0 To use the same VPN tunnel subnet for both connections is definitively not a good idea. But that doesn't matter if you do NAT. Access from a VPN1 client to the FW2 management interface can also be enabled by an outbound NAT rule at FW1. Here you just need to enter the FW2s LAN address at destination.

Firewall rules are generally used to block connections coming into the firewall on an interface. If you want to stop hosts on LAN from making certain connections, then you place those block rules on LAN. If you want to block connections coming in from remote OpenVPN sites, you put those rules on OpenVPN. If you want to block connections going to a remote OpenVPN site, then either block them on the incoming interface (like LAN) or block them at the remote side inbound on OpenVPN. They are the ones "locking their door" against incoming connections. It's possible to block in the outbound direction using floating rules. If you think about the security aspects of what the firewall is supposed to be doing, this is really the only model that makes any sense. https://doc.pfsense.org/index.php/Firewall_Rule_Basics https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting