In anyone is still interested, here is how I got it to work with 3 pfsense setup.

I wanted to setup an environment where I have a datacenter and a remote lab.
All machines in the datacenter have the domain datacenter.home.arpa.
All machines in the lab have the domain lab1.home.arpa.
I wanted machines in the lab to be able to reach machines in the datacenter.

pfSense1:

Hostname: pfSense Domain: home.arpa WAN (dhcp) LAN: 192.168.0.1 Block private networks and loopback addresses: Unchecked Forward packets for datacenter subnet 192.168.2.0/24 to datacenter router - 192.168.0.2 Added gateway Name: datacentergw Interface: LAN Gateway: 192.168.0.2 Added static route Network: 192.168.2.0/24 gateway: datacentergw

pfSense2:

Hostname: pfSense Domain: datacenter.home.arpa WAN: 192.168.0.2 (static) LAN: 192.168.2.1 Block private networks and loopback addresses: Unchecked NAT Forward ICMP and TCP/UDP from source:192.168.0.0/16, destination: LAN net to LAN Address This automatically added necessary firewall rules as well

pfSense3:

Hostname: pfSense Domain: lab1.home.arpa WAN: 192.168.0.3 LAN: 192.168.3.1 Block private networks and loopback addresses: Unchecked DNS Add a domain override for datacenter.home.arpa and send its queries to datacenter DNS: 192.168.2.1 DHCP Set lab1.home.arpa;datacenter.home.arpa as DNS Search

@stewart Just wanted to report that this was the solution. Thanks @johnpoz!

@dataideas-josh Yeah I need to get back to testing this soon.

@operations no one with an idea?

pfSense from what I've seen won't work if the gateway is the same on both WAN interfaces.
Are you doing this in a VM environment or BareMetal?

thanks so much for the help @viragomann and @johnpoz , I seem to have a working route out now with FW rules using policy route!

@jaspery Based on my 2nd episode with crash, I suspect it was crash that caused my dpinger to fail (in this case).

@ashtonianagain Can't speak to Wireguard but we've used it for our office (behind our building router) for many years and have had port forwards set up at several clients that put the router in a DMZ.

There is a guide at https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-port-forwards.html but if it connects initially it would seem the forwarding is correct. Unless maybe it's trying to use additional ports?

There are examples for Wireguard setup.

@latimeria

I think you will get the most out of this video on YouTube.

How to use Multiple WAN on pfsense for Fail over and or Load Balancing

@chrisjx

Maybe I'm over thinking it and it's just a different way to do what DDNS does but for a non-ip CGNAT service.

You need a so called jump host in the internet, free to reach from else where, that is connected to you home network.

Thats it, at a "Hoster" of your choice for some coin
per month and all is done.

@steveits Yes, it was surprisingly easy to set up the 1:1 NAT logic. For the Medusa, its used for someone who rents single office tenant spaces to their own clients so lots of small VLAN's with one or two clients requesting public IP's directly.

@cool_corona
IPsec Site-to-Site VPN Example with Pre-Shared Keys

If you want to allow access to a small segment of the LAN subnet you can state this in the phase 2 at "Local Network", type "Network".
Additionally you need a firewall rule on the IPSec tab to allow access. Here you can also state an alias with single IPs and ports as destination to lock permission down to the necessary destinations only.

Guys, i am still working on this trying to configure it. I think i am doing some kind of progress. Please bear with me as today i don't have that much time. I'll come back tomorrow.

Thank you for all your advises!

@computingdon You'll need to post details. The source address of the connection, the route back to it, the firewall rules passing that traffic when it enters pfSense, and the outbound NAT rules.

@lnguyen said in Can't Route Site To Site:

@dma_pf What are the allowed networks under "Peers" for both sites?

Thanks for pointing me in this direction...that was it! There was an error in one of the peer IP addresses:

00155179-c7b4-4b05-be81-a0a7f79d6e1c-image.png

The Site 2 network should have been 192.168.164.0.

I made the error of seeing that the Wireguard handshake was completed and made the assumption that by doing so it was confirming that: 1) the cryptographic keys matched and 2) that the peer trying to connect had come from the Allowed IP networks. As a result I never rechecked the peer Allowed IPs because I saw a successful handshake.

But now I've got to dig deeper into the Wireguard protocol as it appears that the handshake only requires the keys to match and the Allowed IPs are only used as a routing ACL to allow or reject traffic across the tunnel.

Thanks again for your help!

@jazzl0ver ahhh ok not available in the kernel. That makes sense.

@viragomann

Ok yeah, that makes sense, now that you mention it, I've seen that before. Just not something I typically pay attention to. Guess that leaves me pretty well stumped here.