@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.
a81384b2-9851-4ef9-8814-327a8b2cbe0a-image.png

Now, I'm even more confused.

I've unchecked:

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.

@Sebastian_IT said in Site to Site OpenVPN - Unable to ping remote subnet from local LAN:

Local network Range - 10.0.1.1/24
Remote network Range - 10.1.0.1/24
Tunnel network range - 10.2.0.1/24

No one of these is a network address! These are IP addresses.
So edit you firewall rules and set correct network addresses as source and destination.

BTW: In you firewall rule on server and client you have exactly the same address in source and destination. That doesn't make in sense at all.

@johnpoz said in Same ip subnet for two VPN:

Some other advice 192.168.1 is not a good choice to be honest.. This is very very common - say your at a starbucks or something needing to vpn in to your site and they are using 192.168.1 locally.. Now you have a problem.. Client thinks that your server 192.168.1.100 for example is just local - and won't send it down the tunnel to get to it.

Yep, I had that problem years ago when I was staying at hotels. That's why I moved my LAN to 172.16.0.0. I have only seen that used elsewhere once.

I resolved the issues....

To start with, Windows Firewall was blocking the creation of the log file. When I disabled it, the file was created. What's odd is that I eventually enabled the Firewall and logging continued to work.

Once there was a log file, I used IASViewer to sort out the log file. It showed me that the error was: "Did not match connection request policy". I checked the policy and found that for "Type of network access server" I had selected "Remote Access Server(VPN-Dial up)". Changing it to "Unspecified" resolved the issue.

@johnpoz FML thanks for your help. I didn't click the enable check box on the port forward on the wrt.

@jarrod1024 said in Allow remote access vpn clients to connect across site to site vpn:

I dont see an option to add remote networks on the site B site to site config, only local networks.

Never seen that!
The "Remote Networks" box is available on all sort of site2site OpenVPNs, if its server or client, shared key or TLS.

@johnpoz
Had a moment of weakness. Confused it with pinging TO localhost in terminal. Rookie booboo like we all do at times.