Implementing Site-to-Site as Client-to-Client, not Client-to-Server
I have been using both OpenVPN and pfSense for a long time and I noticed a mismatch in how pfSense documentation is proposing the simple Static Key OpenVPN Site-to-Site implementetion.
Ref. OpenVPN doc:
For its site to site example, pfSense is actually implementing a client-to-server, while OpenVPN implementation is a perfectly symmetric site-to-site.
The OpenVPN "static-key-mini-howto", in terms of pfSense would be implemented as:
pfSense in site A defines an OpenVPN Client as usual, pointing to site B public IP
pfSense in site B defines an OpenVPN Client as usual, pointing to site A public IP
Neither in site A nor in site B pfSense OpenVPN client definition a "IPv4 Tunnel Network" should be defined, that is leave the text box blank.
Instead the tunnel network should be defined with the "ifconfig [local tunnel ip] [remote tunnel ip]" in the Advcanced Configuration > Custom options box.
Of course in site A and Site B the [local tunnel ip] and [remote tunnel ip] should be reversed.
Example, if the desired tunnel network should be 192.168.1.0/30, then the Custom option can be:
(in site A) ifconfig 192.168.1.1 192.168.1.2
(in site B) ifconfig 192.168.1.2 192.168.1.1
And this actually works as the original OpenVPN documentation proposed.
This differs from the Client-Server proposed by pfSense examples because:
in case of multiple sites (say A, B, C), this is no more a hub/spoke setup, but is a perfectly flat mesh in which a remote site talks to another remote sites only via an additional dedicated remote-remote client-client OpenVPN tunnel (or possibly via an additional "remote LAN option", still haven't tested it)
on site A, let's call it the Server site in pfSense examples, packets coming from remote sites appear to arrive with their real source IP addresses, not masked by the site A pfSense's LAN IP address
I aks you please to test this setup, and discuss it so we can eventually find weak points, or if this breaks any other pfSense functionalty I am not yet aware of; I've thoroughly read through documentation and this forum, but haven't found anyone with a similar setup.
Thank you all
If you want a mesh rather than hub-and-spoke, it's easier to do "server-to-server" than "client-to-client", just configure each side as a static key server and then add
remotelines to the custom options.
It is true that OpenVPN is perfectly happy acting in a symmetric fashion, but most users are not comfortable with that concept, so our interface is geared toward making it easier for users to implement. We don't document it because it's rare to need both sides to act in the same role.
Thank you Jim for the super-quick reply.
Actually I am a much more exerienced OpenVPN user than pfSense user, so I know that OpenVPN is happy with that setup, I was just wondering if that client-to-client (or server-to-server as you pointed out) could be a problem for pfSense itself and all its other features.
What headed me to this test was the fact that I didn't like the packets coming from remote sites to be masqueraded with the local pfSense LAN interface IP address; i just wanted them to be plain with their original IP; and I didn't want to fiddle with special NATting for the packets coming from remote sites.
This also makes me think: in a symmetric server-to-server setup as you propose, will the packtets be masqueraded on both sides with the local pfSense LAN IP address?
I'll test this in a short while, and report here, if anyone interested.
Thank you all
NAT wouldn't happen automatically in any case with OpenVPN. You have to go out of your way to make that happen. It's bare routed IP traffic no matter which method you choose, unless you have setup the other interfaces and/or NAT rules in a way that makes that happen.
Hello Jim, thanks for your suggestions, of course you were right.
On the LAN side I had a default gateway to reach some internal subnets, which tricked pfSense into thinking that LAN was actually a WAN.
I suppose that this was the reason that caused the masking of packets routed by OpenVPN and directed downstram via the default gateway.
The setting of Firewall > NAT > Outbound was and remains "Automatic outbound NAT rule generation.
(IPsec passthrough included)".
Added the proper static routes on LAN side, removed the default gateway on the LAN side, everything was back to work as expected, that is: no automatic masquerading happening for packets coming from remote OpenVPNs.
Lesson learned: the "add gateway for WAN, none for LAN" advice during setup process is there for a reason.
Thank you again