To map a remote fake subnet through an IPsec tunnel without modifying the remote device, configure pfSense Phase 2 proposals to match the remote network exactly and disable NAT for that specific traffic. By defining the local and remote subnets in the IPsec wizard to reflect the actual logical networks rather than physical interfaces, you ensure packets are routed correctly through the encrypted tunnel while preserving the remote site's existing addressing scheme.
Understanding the Subnet Mismatch
The core challenge in this scenario is bridging two different address spaces: a local network using 10.0.0.0/16 and a remote network using a private range like 172.16.0.0/24. The term "fake subnet" implies that the remote site does not have a route back to your 10.x.x.x space, or they cannot change their configuration to accept it. Standard routing would fail because the remote gateway does not know how to reach your internal LAN.
In previous incorrect approaches, administrators often attempted to use Proxy ARP on the pfSense interface. This is technically flawed for IPsec because Proxy ARP operates at Layer 2 and can cause conflicts with the encapsulation headers used by IPsec. Instead, the solution relies entirely on correct Phase 2 (Quick Mode) definitions and proper NAT exclusion rules. You must treat the IPsec tunnel as a direct wire between two routers, where each side sees its own subnet and the other side's subnet.
Configuring the IPsec Phase 2 Proposals
The most critical step is ensuring that the Phase 2 proposal accurately reflects the traffic that will traverse the tunnel. In the pfSense IPsec wizard, you will define the Local Network and Remote Network. Do not select the entire WAN interface or the default LAN subnet if they do not match the logical scope of the connection.
- Local Network: Select the specific subnet within your
10.0.0.0/16range that needs access to the remote site. If all internal hosts need access, you may select the entire LAN subnet, but be aware of routing implications. - Remote Network: Enter the exact CIDR block of the remote site, such as
172.16.0.0/24. This tells pfSense that any destination IP falling within this range should be sent through the IPsec tunnel rather than out the WAN interface.
If the remote site has multiple subnets behind their firewall, you must add additional Phase 2 entries for each distinct network. Each entry acts as a static route pointing into the encrypted pipe. Failure to include a specific subnet in the Phase 2 definition will result in traffic being dropped or routed incorrectly via the default gateway.
Excluding Traffic from NAT
Even with correct Phase 2 settings, traffic will fail if pfSense performs Network Address Translation (NAT) on packets entering the tunnel. By default, pfSense applies outbound NAT to all traffic leaving the LAN. For IPsec tunnels, you must create exceptions so that traffic destined for the remote subnet retains its original source IP address.
Navigate to Firewall > NAT > Port Forward or Firewall > NAT > Outbound, depending on your NAT mode. If you are using Automatic Outbound NAT, pfSense generates rules dynamically. You must manually edit these rules to exclude the traffic matching your IPsec peers.
- Go to Firewall > NAT > Outbound.
- Switch to manual mode if necessary to gain full control over the rules.
- Create a rule that matches Source: Your LAN Subnet (
10.0.0.0/16) and Destination: The Remote Fake Subnet (172.16.0.0/24). - Set the Action to No NAT or Passthrough.
- Place this rule above the general NAT rule that translates all LAN traffic to the WAN IP.
This ensures that when a host in 10.0.0.5 sends a packet to 172.16.0.10, the source IP remains 10.0.0.5 inside the tunnel. If you were to translate this to the WAN IP, the remote site would reject the packet because it expects traffic from the specific internal range, or the return path would become asymmetric.
Verifying Route Domains and Policy Routing
Once the tunnel is established, you may encounter issues where return traffic does not flow correctly. This is often due to pfSense choosing the wrong interface for the return path. While IPsec handles the encryption, the underlying routing table must prefer the tunnel interface for the remote subnet.
Check the Diagnostics > Routes page to verify that there is a specific route for 172.16.0.0/24 pointing to the IPsec tunnel interface (often named enc0 or similar). If no specific route exists, pfSense might send reply traffic out the WAN interface, causing asymmetry. You can force this behavior by adding a static route in System > Routing > Routes, setting the destination to the remote subnet and the gateway to the IPsec tunnel.
For more complex setups involving multiple interfaces, consider reviewing how pfSense handles asymmetric routing scenarios, as similar principles apply to ensuring traffic enters and exits through the same logical boundary. Understanding these routing mechanics prevents common connectivity failures after initial configuration.
Troubleshooting Common Failures
If the tunnel fails to establish or traffic stops flowing, check the following areas first. Verify that the Phase 1 (Main Mode) parameters, such as DH groups and encryption algorithms, match exactly between both ends. A mismatch here will prevent the tunnel from coming up entirely.
If the tunnel is up but ping fails, inspect the packet capture on the pfSense WAN interface. Look for ESP packets (Protocol 50) being exchanged. If you see ESP packets but no ICMP replies, the issue is likely downstream at the remote firewall or within the NAT rules on pfSense. Ensure that the remote firewall allows traffic from the 10.0.0.0/16 range, as it will appear as the source after decryption.
Additionally, verify that no other firewall rules on the LAN or WAN interfaces are blocking the traffic before it reaches the NAT engine. Rules in pfSense are processed top-down, so ensure that allow rules for the remote subnet are positioned correctly relative to any deny-all policies.
Frequently Asked Questions
Can I use Proxy ARP to solve the subnet mapping issue?
No, Proxy ARP is not suitable for IPsec tunnel mapping and can cause significant network instability. It operates at Layer 2 and interferes with the encapsulation process required for secure tunnels. Always rely on Phase 2 definitions and NAT exclusions instead.
What happens if I forget to disable NAT for the remote subnet?
If NAT is not disabled, the source IP of the packets will be translated to your WAN IP. The remote site will receive traffic from an unexpected address, which may be blocked by their firewall or cause routing loops. This results in one-way communication or complete failure.
How do I handle multiple remote subnets behind one peer?
You must create separate Phase 2 proposals for each distinct subnet. Each proposal defines a specific destination range that should be encrypted. pfSense will evaluate these rules in order, sending traffic to the correct tunnel interface based on the destination IP.
Why is my IPsec tunnel up but I cannot ping the remote host?
This usually indicates a routing or firewall issue rather than a tunnel establishment problem. Check that the remote host has a route back to your 10.0.0.0/16 network and that no intermediate firewalls are dropping the decrypted packets. Also, verify that your pfSense NAT rules are correctly excluding this traffic.
Does this configuration affect other internet traffic?
No, provided you have correctly configured the NAT exclusion rule. Only traffic destined for the specific remote subnet will bypass NAT and go through the tunnel. All other internet-bound traffic will continue to use standard outbound NAT and the default WAN gateway.