A definitive, example-driven, OpenVPN Reference Thread

[Derelict]

So I updated the diagram to include an IP subnet conflict so I could lab a "Site-to-Site with conflicting subnets."  Attached are my 1:1 NAT Configs.  It's pretty straightforward.

Interestingly, I found that all traffic relating to the translated networks is passed despite rules on pfSense A's OVPNS1 interface.  My test connection was ssh from Host B2 to Host A2.

Even with a reject any any the traffic was passed, as is evidenced by the third screenshot.  With that rule in place and after clearing states on pfSense A, I could still ssh from Host B2 to Host A2.

Is this normal and expected behavior for 1:1 NAT?

[jimp]

@Derelict:

Even with a reject any any the traffic was passed, as is evidenced by the third screenshot.  With that rule in place and after clearing states on pfSense A, I could still ssh from Host B2 to Host A2.

Is this normal and expected behavior for 1:1 NAT?

You did not show the rules on your OpenVPN or floating tabs. If something there passes the traffic, it does not matter what is on your ovpnc1 interface rules.

The order of processing for rules is:

1. Floating rules
2. Group rules (such as the OpenVPN tab)
3. Interface rules (such as your assigned OpenVPN interface tab)

In order for your assigned tab rules to apply, the OpenVPN tab must be completely empty, or at least have rules crafted that could never match the traffic for the other VPN.

[Derelict]

OpenVPN tab has no rules.  The only Floating rule is a Reject all on WAN out when marked NOEGRESS.

[Derelict]

Hang on.  Now I'm getting connection refused like I'm supposed to.  Let me look at this all again.  Thanks and sorry for wasting your time.

Yeah.  This is working fine.  Disabling and enabling the ssh rule below has the expected behavior.  Must have been a pre-existing state issue or something somehow.

[Derelict]

Another question was asked here: https://forum.pfsense.org/index.php?topic=86440.0

How do I route specific internet sites through an OpenVPN client connection while leaving other client internet traffic alone?

Commonly called split tunneling.

Steps are:

• Push routes for the traffic you want to go over the OpenVPN tunnel to the clients

• Allow traffic to those destinations into your server's OpenVPN firewall interface

• Ensure your server will NAT for the OpenVPN clients if required

See the attached screenshots.  I used the IP addresses for www.whatismyip.com at the time of this writing.  Note that this is with an OpenVPN assigned interface.  I do not think this is necessary since NAT is happening on WAN, and not OpenVPN.  Pass rules on the OpenVPN tab should work.  I don't configure any OpenVPNs without assigned interfaces anymore.

ETA:  In a production environment do this in the opposite order.  Set up the rules and NAT then push the routes to the clients.  ;)


[Derelict]

Another question just came up here:

https://forum.pfsense.org/index.php?topic=86533.0

I currently have a hub and spoke ipsec vpn set up with communication working only from each spoke to the hub not the other spokes. I would like to migrate to an open vpn setup for many reasons but the main one being that I can get a hub spoke network with inter-spoke communication.

This is pretty simple with OpenVPN Site-to-Site.

I have altered the diagram below to include two OpenVPN spokes (B & C) to central hub pfSense A.

General steps are:

• Push supernet route for 172.26.0.0 255.255.0.0 to all spokes (All clients on the OpenVPN server instance.)

• iroute individual subnets to the correct tunnel

• Ensure OpenVPN firewall rules permit inter-spoke traffic

That's essentially it.  Each site controls what, if any, connections are allowed into it via the firewall rules on its OpenVPN interface (or OpenVPN Tab).  All that's necessary is for all sites to route all traffic for the supernet (172.26.0.0/16 in this example. 192.168.0.0/16 in OP's case) over the tunnel.  This is accomplished with the push "route 172.16.0.0 255.255.0.0" directive on the server.  OP, you are almost certainly going to have collisions with other VPN networks, home networks, etc.  You might want to renumber off 192.168.0.0.  Especially if you're going to revamp your entire VPN.

Achtung

The use of the custom options for routes and iroutes is almost certainly no longer necessary in current versions of pfSense. Routes should be put in the Remote Networks, push routes should be in Local Networks, and iroutes should be put in Client-Specific overrides. If there is a gui widget for something it should be used for a configuration item instead of custom options.

[Derelict]

Should be similar to this:

[Derelict]

A lot of this was unnecessary. I know better now.

Just put the networks in the Local and Remote networks and let it add the route statements to the config.

Just use Client-specific overrides and let them put the iroute statements in the config.

[oarie]

Thank you Derelict! This is a very helpful topic.

[Derelict]

macOS spotlight and never deleting anything for the win. :)