@rustydusty1717 I know this is an old post but how do i perform these chances to the MTU/MSSFIX. There is no clear instructions on how to perform any of this.

OpenVPN and IPSec have no problem whatsoever in co-existing and having tunnels defined. If stopping IPSEC makes your OVPN tunnel work, you have it wrong. Most commonly you are probably using the same subnets on OVPN as in IPSEC or try to route a network that is already defined in IPSEC. Without your config, that's all we can guess.

every time someone had this problem on the forum it turn out to be a routing issue, check if this help, https://forum.netgate.com/topic/127348/openvpn-only-works-for-a-single-user-at-a-time there is a workaround at the end but i think is a not necessary hack as i'm pretty sure there is something wrong he did somewhere else. Open a new 3d with your problem, this is old and not related.

Traffic selectors have nothing to do with whether or not the authentication is RSA or shared-key. Configure your routing and traffic selectors properly and it will work. There is not going to be a walkthrough specific to your scenario unless you yourself write it. You'll have to post more details about your situation to get more specific assistance.

@johnpoz said in How to bypass VPN for FTP: So your policy route rule would really need to be for the dest IP and any port.. Unless you know the range of ports the server is going to give you for the passive connection.. That should work, thanks for the suggestion. Will give that a try.

I think there should be an option on the client settings to force all traffic through the tunnel. Maybe this will help: https://forum.netgate.com/topic/135500/force-lan-traffic-through-openvpn-tunnel Not sure if that stops Internet if the tunnel is down. Maybe you can try a firewall rule to block outbound traffic to the WAN and only allow traffic over the OpenVPN firewall rules.

https://community.spiceworks.com/how_to/34667-setup-open-vpn-with-pfsense-carp-and-quagga-ospf This is what I have had working for last year and some. I ran into a bug using ovpn and ipsec together that causes radius packets to become malformed. If you are not using radius logins across the vpn then all works great.

@jaredmeakin said in Just setup pfSense at home, and I can't connect to my "works" OpenVPN.: I'm using DNS Resolver with out of the box configuration, and on System > General Setup I have two DNS servers listed (8.8.8.8 & 8.8.4.4). When a device on your LAN, behind the home pfSense router, connects to the companie's VPN server, that device will use the DNS that the VPN server has instructed to the VPN client. Also : look up DNS related info - if any exists, in the VPN client config setup. It's rather logic to use the pfSense's resolver, because that DNS source is aware of all the local devices at work. When I call in to work from home (both sides a pfSense as router/firewall) I've set up the VPN server (pfSense work is my VPN server) I instruct the clients (= my PC at home) to use the pfSense's DNS server == the Resolver. Btw : I have no business with "8.8.8.8" or "8.8.4.4" neither "AWS".

Update: Thanks to this guide: https://blog.monstermuffin.org/tunneling-specific-traffic-over-a-vpn-with-pfsense/ I need to do two more things on the vpn client settings: check the "Don't add/remove routes" add "route-nopull" in the Custom options Now it works as it should be, i.e., my virtual AP VPN_BBC has 7/24 vpn whilst my other subnets have normal internet traffic. [image: 1573538112759-a81384b2-9851-4ef9-8814-327a8b2cbe0a-image.png]

Now, I'm even more confused. I've unchecked: [image: 1573498729626-bildschirmfoto-vom-2019-11-11-19-57-53.png] Now, I can connect to local devices and the internet. I thought, if i disable these options, my "public" IP would be the one of my cellphone I'm using as a hotspot for testing purposes, but it's not the case. So I would guess, all traffic is still beeing passed through the VPN connection. No I have to fight my next issue: I can only reach some of my local devices, I guess it has to do with my (inproper) VLAN setup

Yeah.. Just because its not broken doesn't mean there is not a better more current recommended choice vs following old guides..

Yes otherwise openvpn sets the default route to go via the openvpn connection. Have a look at the routing table pre and post change.

@JKnott said in Best practice block local users from accessing VPN: @ScottCall Perhaps you cancreate a rule to block access from the LAN. You'd put it on the LAN interface, to block going to the WAN address. That was my plan I just wanted to know if there was a more recommended way before I did. I'll do that. Thanks -S

That's up to your authentication server, not OpenVPN. Some things like Google Authenticator can easily integrate into RADIUS to be used in place of a password (pin+code = password when logging in), I'm not sure of any that work with an OOB step in between, but again that's entirely up to the auth server.

It looks to me like a bug in OpenSSL CRL validation with certificates signed by an intermediate CA, and not necessarily with OpenVPN or pfSense. I've tried several different methods but I haven't been able to get a working result from an intermediate CA CRL with OpenVPN or even OpenSSL directly. I get similar OpenSSL failures on pfSense, FreeBSD, and Linux so it does not appear to be isolated to pfSense. I've opened https://redmine.pfsense.org/issues/9889 with some details, but I may need to open a bug report upstream in OpenSSL as well.

I'm going to answer my own question... the php is very easy to read. /usr/local/www/vpn_openvpn_client.php if ($act == "new") { $pconfig['ncp_enable'] = "enabled"; $pconfig['ncp-ciphers'] = "AES-128-GCM,AES-256-GCM"; $pconfig['autokey_enable'] = "yes"; $pconfig['tlsauth_enable'] = "yes"; $pconfig['autotls_enable'] = "yes"; $pconfig['interface'] = "wan"; $pconfig['server_addr'] = 1.1.1.1 $pconfig['server_port'] = 1194; $pconfig['verbosity_level'] = 1; // Default verbosity is 1 $pconfig['digest'] = "SHA256"; $pconfig['compression'] = "none"; Thanks!

Above you mentioned to add CSO for each user. By that you can control the virtual IP addresses the user get. So if you have two user groups which should get different permissions you can assign group 1 the tunnel network 10.10.22.0/26 und group 2 10.10.22.64/26. Then you may use that subnets in your firewall rule as source networks to control access of each user group. As well you can set "IPv4 Local Network/s" in the CSO. These settings are pushed to the clients. So there is no need to edit the client config files. In the outbound NAT rule, if you want restrict, you can use aliases by selecting Network and enter the alias into the network box. However, as mentioned, if you restrict access in the firewall rule already there is no need to do that in the outbound NAT additionally.