Step-by-Step Guide for Source NAT on pfSense Firewall to Reach Network Behind IPsec Tunnel
-
Step-by-Step Guide for Source NAT on pfSense Firewall to Reach Network Behind IPsec Tunnel
Hello everyone,
I need assistance with configuring Source NAT (sNAT) on my pfSense firewall to allow traffic from Site-A to access a host behind Site-B, using Central-PF as a transit firewall. I've tried multiple Source NAT configurations to reach Site-B, but none of them worked so far. I'm hoping someone can help identify what might be missing or misconfigured.
Below is the detailed network topology and the requirement.Network Scenario
Central-PF (pfSense 1 - Central Site)WAN: 192.168.64.200/24 LAN: 10.0.10.10/24
IPsec Tunnels:
IPSec1: Central_to_Site-A Local Subnet: 10.0.10.0/24 Remote Subnet: 192.168.10.0/24 IKE Version: V2 Protocol: ESP Encryption: CHACHA20-POLY1305 Integrity: SHA256 PFS Key Group: 14 (2048-bit) IPSec2: Central_to_Site-B Local Subnet: 10.0.10.0/24 Remote Subnet: 172.16.10.0/24 IKE Version: V1 Protocol: ESP Encryption: AES (256-bit) Integrity: SHA1 Lifetime: 86400s Rekey Time: 77760s Rand Time: 8640s PFS Key Group: 14 (2048-bit)
Site-B (Unknown IPsec Firewall)
WAN: 192.168.64.210/24 LAN: 172.16.10.10/24
IPSec Tunnel:
Site-B_to_Central Local Subnet: 172.16.10.0/24 Remote Subnet: 10.0.10.0/24 Same configuration as above (IKE V1, AES 256, SHA1, etc.) ⚠️ Note: I do not have administrative access to the firewall at Site-B.
Site-A-PF (pfSense 2 - Site-A)
WAN: 192.168.64.220/24 LAN: 192.168.10.10/24
IPSec Tunnel:
Site-A_to_Central Local Subnet: 192.168.10.0/24 Remote Subnet: 10.0.10.0/24 IKE Version: V2 Protocol: ESP Encryption: CHACHA20-POLY1305 Integrity: SHA256 PFS Key Group: 14 (2048-bit)
Goal:
I want to allow a host at Site-A (192.168.10.100) to access a host at Site-B (172.16.10.100).
Since Site-B only has an IPsec tunnel established with Central-PF (and not with Site-A), I need to perform Source NAT (sNAT) at Central-PF.
Expected NAT Translation:Source: 192.168.10.100 (Site-A) Destination: 172.16.10.100 (Site-B) Translated Source IP: 10.0.10.10 (Central-PF’s internal IP) The return traffic should follow the same IPsec path back through Central-PF to Site-A.
Request:
Can someone please provide a step-by-step guide to achieve this Source NAT configuration on Central-PF (pfSense 1)?
Preferably with:
Firewall/NAT rule configuration steps IPsec phase 2 considerations (do I need to add new Phase 2 entries?) Any special routing or policy-based routing settings How to test and confirm it's working
Thank you in advance for your help!
-
@Grigor
Maybe you have luck with these steps:Add a phase 2 to central - A connection:
Central:
local subnet: 172.16.10.0/24
remote subnet: 192.168.10.0/24A:
local subnet: 192.168.10.0/24
remote subnet: 172.16.10.0/24Pick an unused IP of the central LAN, say 10.0.10.111.
Add a phase 2 to central - B connection:
Central:
local subnet: 192.168.10.0/24
BINAT: address > 10.0.10.111
remote subnet: 172.16.10.0/24
Move this p2 up to the top.I want to allow a host at Site-A (192.168.10.100) to access a host at Site-B (172.16.10.100).
Just use 172.16.10.100 to access the remote host.
Ensure that the firewall rules at the central allows it. -
@viragomann
Thank you for your response — I really appreciate you taking the time to help.However, I’ve already tested the exact scenario you're suggesting. Unfortunately, it didn’t work in my case. What I’m specifically looking for is feedback from someone who has successfully implemented Source NAT in a setup that matches my parameters, particularly:
Site-A to Central-PF using IKEv2 Central-PF to Site-B using IKEv1 NAT at Central-PF, where Site-A is NATed to Central’s LAN IP before forwarding to Site-B
I’m aware that when both IPsec tunnels use IKEv2, NAT works fine and there’s no need to configure BINAT or additional Phase 2 entries. However, in my situation — with mixed IKE versions — the NAT rule doesn’t appear to work as expected.
If anyone has resolved this exact case or has real-world experience with this specific type of mixed IKE/IPsec/NAT scenario, I would greatly appreciate your insights.
Thanks again!