looking for advice on implementing site to site VPN
-
The good news is that appears to be a fairly simple use case that shouldn't give you much trouble. Just a matter of getting the phase 2 entries and/or routing setup right. Even printing should be fine provided you can contact the printers by IP address and assuming they allow being contacted from off their main subnet. Lots of printers can but it's hard to say whether or not that's universal.
IPsec would be the best solution there, especially on that hardware. Use AES-GCM and make sure the SafeXcel module is active under System > Advanced, Misc tab. WireGuard would be a good second choice. I would avoid using OpenVPN.
-
Thanks for the input. From my research so far, IPSec has seemed like the best solution for me. I will keep on reading, with a focus on IPSec.
Wireguard did seem like an interesting solution that I was seriously looking at before it was removed from FreeBSD and pfsense. Seemed like a pretty straightforward configuration that would have met my needs. Once the current package is further along in development it is something I would like to revisit.Any further advice is still welcome. And I am sure I will have some more questions as I get closer to actually implementing.
Thanks again.
-
@pzanga IPSec with VTI, then use BGP for the routing. Works really well and you can even push default routes using BGP, or just use Policy Based Routing (PBR) and gateway groups.
-
Thought I'd give some quick follow-up since I finally had time to set this up.
I went with IPsec using AES-GCM as suggested and enabled the SafeXcel module. I used tunnel mode for phase 2 as that seemed simplest at this point, given my knowledge/comfort level.
The tunnel connects and I can ping the various devices (network printers, APs, managed routers, etc) at the remote site in either direction, i.e. Site A-->Site B or Site B-->Site A, as well as connect to their web UIs.
However, I cannot ping any of the remote PCs (Windows 10, Windows Server 2012 R2) in either direction. I can ping them locally. I'm assuming it's not due to the firewall/pfsense since I can connect to anything not a PC. But never assume, right? IPsec firewall rules are configured to allow any/all on both sides.
I'm just starting to dig into this, but I don't see anything obvious in the network settings on my PCs and haven't found any posts describing the same situation. I'll likely put up a new post once I have more info, but any thoughts on where to focus my efforts would be appreciated. -
Typically that would be Windows firewall on the PCs configured to allow traffic only from their own subnet. Since you are now trying to connect from a remote subnet they reject it.
You can test that by adding an outbound NAT rule on the pfSense LAN at the remote end. PCs will then see the traffic as coming from the pfSense LAN IP and allow it. That should be a test only though. If it works then add the remote subnets as allowed on the PCs you need to reach.Steve
-
@stephenw10
Thanks. That makes sense. From my researching so far it looks like Windows firewall is the likely culprit.
I'm just not sure exactly how to configure the outbound NAT rule. I think it would be as follows:
Site A=main office Site B=satellite (remote) office, setting up rule on pfsense at Site BInterface: IPsec
Address family: IPv4 (we don't use IPv6)
Protocol: Any
Source: Network, Site B subnet 192.168.0.0/24
Destination: Network, Site A subnet 192.168.0.0/24
Translation
Address: Interface address or other subnet? - this one I'm not clear onAppreciate any help.
(edit - I hit submit before I was done)
-
In order to access a PC at site B from site A the OBN rule would have to be on the LAN interface at site B and match the traffic coming from site A. That way it translates the source IP to the site B LAN B IP and hosts there see it as coming from their subnet.
Steve
-
@stephenw10
Thanks Steve. Pretty sure I get it now.
So the interface would be the LAN,
Source would be the Site A subnet,
Destination would be Site B subnet,
Address would be Interface address (the IP of the LAN).I was making the mistake of thinking Outbound is always outbound to the internet, instead of outbound from the interface in question (i.e. traffic inbound from the internet to the WAN interface becomes outbound from the LAN interface to the LAN).
Would it be an oversimplification to say Inbound NAT is used to modify/change the destination of traffic across an interface, and Outbound NAT is used to modify/change the source of traffic across an interface? I don't see that as part of any definition I have found, but seems to be one way to look at it. But I digress from the topic at hand.Thanks again.
-
Yes, outbound NAT is Source NAT. You might also see that as S-NAT in some places.
Further reading : https://www.freebsd.org/cgi/man.cgi?pf.conf(5)#TRANSLATION
Steve
-
@stephenw10
Thanks again. The test worked. So now I'll update the individual PCs as needed.And thanks for the reading material. I really appreciate it.
-
@pzanga said in looking for advice on implementing site to site VPN:
@stephenw10
Thanks again. The test worked. So now I'll update the individual PCs as needed.And thanks for the reading material. I really appreciate it.
If your Windows devices are part of an Active Directory Domain, you can easily manage the Windows Firewall policies via Group Policy. Here's a link to some Microsoft documentation: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/open-the-group-policy-management-console-to-windows-firewall-with-advanced-security. What you will want to do is add "allow" rules for traffic inbound from your remote site networks.