A definitive, example-driven, OpenVPN Reference Thread

[Derelict]

I can think of several reasons.  One would be so you can maintain one public facing firewall with pass rules.  The other site could be locked down for everything.  An OpenVPN client doesn't even need to listen on its OpenVPN port.

It could also be used if you are migrating a data center and need to change DNS to the outward-facing IPs at the new one but still hit servers in the old datacenter until you can move them.  Make NAT rules over the VPN to the old datacenter, Change DNS, migrate a server, change the NAT rule to the local server.  Repeat until done.

My second exercise will be the reverse, which is site B accessing the internet through the tunnel to site A.  That can obviously be used to egress from different locations.  There are at least a couple current threads asking how to do this.

[Derelict]

Ok.  So I got my first recipe working.  ssh to pfSense A’s WAN port (172.27.0.5) on tcp/8022 hits HostB1 on port 22.

This scenario requires special treatment because the source IP of the connection hitting Host B1 will be an outside address.  In my case I go into all these WAN ports from ip addresses on 192.168.223.0/24.  192.168.223.6 specifically.  When HostB1 receives the SSH connection request, it will be from 192.168.223.6.  It will send replies to its default gateway, pfSense B.  pfSense B will not have a route for 192.168.223.6 since it’s a host on the “internet” so it will send the reply to its default gateway, 172.27.0.1. If the reply happens to reach 192.168.223.6, it will be dropped because it will be out of state since the state is expecting replies to come from 172.27.0.5, not 172.27.0.9.

To correct this, two things have to be done on on pfSense B.

• An interface has to be created with the OpenVPN client instance as the virtual interface.

• the firewall rules on the OpenVPN tab have to be set so they DON’T MATCH the traffic between 192.168.223.6 and 172.26.2.100.

First, the ovpnc1 interface:

Warning

This disrupts OpenVPN traffic to pfSense B so don’t do it over the VPN or you’ll be unhappy on your drive to the datacenter.  Do it from LAN or WAN.

I went to Interfaces->Assign and hit the + to create a new interface.  OPT2 was created and I set the Network port to “ovpnc1”.  Then saved.

I then clicked OPT2 to edit it, checked enable, and changed the interface name to OVPNC1 and saved/applied.  It doesn't need addresses or anything.  Just leave IPv4 and IPv6 config types set to none.

You then have to bounce OpenVPN on pfSense B.  I did this at Status->Services and hit the Restart button on OpenVPN.

If you then go to Firewall->Rules, you will see a tab for the OVPNC1 interface and the OpenVPN group.

Now for the OpenVPN Tab firewall rules.

These rules must not match traffic from the internet host through to Host B1.  Many people have pass any any rules in the OpenVPN TAB, as I did for troubleshooting initially setting up the VPN.  This will prevent reply-to from working correctly and will break our attempted NAT translation.  So I edited my OpenVPN tab rules to look like “OpenVPN Tab Rules” below.  Essentially I only pass traffic into the general OpenVPN Tab if it’s from 172.26.0.0/16 - which will be other OpenVPN hosts for which I should get a route pushed from the server if properly configured.

Now for the NAT translation and firewall rules on pfSense A.  This is a just a regular port forward on WAN and shown in “pfSense A port forward 8022”.

This traffic will be seen on pfSense B as coming INTO interface OVPNC1 so it needs a pass rule there or it will be blocked.  That rule is placed on the OVPNC1 interface, not the OpenVPN tab like “pfSense B port 22 rule”.

And you’re done. :)

[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. :)