Site-To-Site VPN Configuration Assistance
I've set up a site-to-site VPN using the guide found here: https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL)
This is the third VPN I have set up using this method, each of which successful until now, however my configuration has differed a little bit in this instance, out of necessity. The "server" side is an pfSense VM set up below a ClearOS router, which is then below a dedicated firewall. This network setup cannot change. My goal is to share the ClearOS subnets (10.1.1.0/24, 192.168.1.0/24) across the VPN to the dedicated pfSense box which will also share back its own LAN (10.2.2.0/24). Everything has been setup exactly as indicated in the guide.
The only difference here is that the network which the pfSense VM is attempting to share is its WAN network. The box is statically assigned an IP of 10.1.1.150, and from it I can ping and lookup DNS entries of everything under both subnets. The VPN bridge itself functions as well – from the "client" VPN box I can also ping and lookup addresses on both subnets across the tunnel. However, on the LAN of the "client" box, no connection can be established, save to pinging the IP of the VPN server.
Any assistance would be appreciated!
After reading your description of the setup I assume that the VPN server isn't the default gateway in the local subnets behind.
In this case you need static route on the local devices for the other site's subnet(s) pointing to the vpn server, or you do NAT on pfSense. If you solve it by natting the source addresses to pfSense WAN address it has the disadvantage that any access from the other site seems to come from pfSense itself. You can't see the origin IP address on the dest device.
The fact that the vpn server pfSense is faces with its WAN interface to the subnets you want to access over vpn would make it possible to access the servers subnets across the tunnel by the client, cause pfSense will do NAT for the tunnel network.
The cleanest solution for your issue is to connect pfSense to a particular interface of the ClearOS router, if you have one (you may also set up a vLAN if not), and set up a transfer network between the router and pfSense. On the router you have to set a static route for the network behind the vpn client pointing to pfsense and on pfSense you should disable NAT (Firewall > NAT > outbound).
If that isn't an option consider to set up NAT with the drawback described above.
To do so, set the outbound NAT to manual mode and add a rule to WAN interface with source = clients LAN (you may also set any here, since the pfSense has no other function), any other options at their defaults.
In either case you have to disable "Block private networks" in the WAN interface settings on the server, since it is in a private network.
You're correct that the tunneled server is not the default gateway – I do serve tunneled DNS via DHCP but I also have failovers, that way if the tunnel ever goes down users under the "client" pfSense box will still be able to access the internet, just not the LAN bridge.
Thought it might be a NATting issue of some kind. I did opt for box #2, as the ClearOS server is a VM in and of itself. I could go through the nightmare of connecting it via a vSwitch with specific routing instructions but since it's all internal and behind several firewalls on both ends of the tunnel anyway, I think it'll be fine. For the intended bridging purpose, it's not the end of the world that all tunneled requests will appear to come from the "server" pfSense VM.
Thanks for the concise and helpful assist. Works perfectly now. +1 to viragomann