Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Step-by-Step Guide for Source NAT on pfSense Firewall to Reach Network Behind IPsec Tunnel

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 287 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      Grigor
      last edited by

      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.

      pfsense Diagram.drawio.png

      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!

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @Grigor
        last edited by

        @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/24

        A:
        local subnet: 192.168.10.0/24
        remote subnet: 172.16.10.0/24

        Pick 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.

        G 1 Reply Last reply Reply Quote 0
        • G
          Grigor @viragomann
          last edited by

          @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!

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.