This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Yet Another 1:1 NAT with IPsec Question - Replicating pfSense BINAT

I know this has been asked and answered multiple times on this forum but I have been unable to get this to work on UTM-9 SG230 Firmware 9.508-10.

I am trying to replicate a BINAT configuration that I had running on a pfSense to now run on the UTM-9 at a different location (and WAN IP). On the pfSense it was very easy since all I had to do was simply set a single BINAT address in the tunnel configuration that I want all traffic to change to as it went through the tunnel and back. Doing this on the UTM has not been nearly as easy since I have to define my "fake" LAN, setup two 1:1 NAT Rules (with auto-firewall checked), and then configure the IPSec GW and Tunnel.

  • My LAN: 172.16.0.0/24
  • Their LAN: 10.24.112.0/24
  • My "Fake" LAN: 10.101.1.0/24 (to avoid a potential conflict on their side - but really because that's how it was originally configured and they don't want to change anything except for the Peer (public) address.
  • Gateways: Keeping that private so just call them My WAN and Their WAN.

So the Remote Gateway and IPsec Connection was easy and the tunnel established without issue and looks the same as what I had on the pfSense (uses a custom Policy).
SA: 10.101.1.0/24=(My WAN) <=> (their WAN)=10.24.112.0/24

REMOTE GATEWAY: Remote Network is 10.24.112.0/24
IPSEC CONNECTION: Local Network is 10.101.1.0/24 (fake)

But the issue I now have is with the 1:1 NATs (2 required I'm told) and routing.

Flow from me to them: 172.16.0.0/24 > (1:1NAT to 10.101.1.0/24) > WAN <=> WAN > 10.24.112.0/24
Flow from them to me: 10.24.112.0/24 > WAN <=> WAN > (1:1NAT to 10.101.1.0/24) > 172.16.0.0/24

So I created two 1:1 NAT rules (grouped)

OUTGOING RULE 1
For traffic from: 172.16.0.0/24
Using service: Any
Going to: 10.24.112.0/24
1:1 NAT mode: Map Source
Map to: 10.101.1.0/24 (Fake)
Automatic firewall rule: Checked

INCOMING RULE 2
For traffic from: 10.24.112.0/24
Using service: Any
Going to: 10.101.1.0/24 (Fake)
1:1 NAT mode: Map Destination
Map to: 172.16.0.0/24
Automatic firewall rule: Checked

if I try to ping from 172.16.0.x/32 to 10.14.112.x/32 I get nothing nor can I establish a connection. If I monitor this in the firewall live log (have log initial packet on) I see it hit RULE 1 but never see it hit RULE 2 coming back. I though maybe I had my Map source/dest mixed up so tried both ways with the same result (no ping).

Right now I only need to connect from a single server on my side to a single server on their side so I suppose I could use SNAT/DNAT but this worked without issue on the pfSense and allows for expansion or host changes on either side with the 1:1 NAT. I do notice that there is no "Rule applies to IPsec packets" option for 1:1 NATs making me wonder if a Full NAT might be a better option for now. I also read in one the posts here that I should also include my "real" local network and my "fake" local network in Local Networks for the IPsec Connection but that really makes no sense and, of course, won't establish the SA for that "real" network.

It seems that a lot of folks struggle with this on the Sophos - even those with lots of Cisco experience (and the remote side of this tunnel is all Cisco).



This thread was automatically locked due to age.
Parents
  • Your 1:1 NATs look good to me, Kipland.  Remember that pinging is regulated on the 'ICMP' tab of 'Firewall' - see #2 in Rulz.

    A Full NAT wouldn't work, but SNAT/DNAT could.  It's not clear to me why you're having trouble though.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Your 1:1 NATs look good to me, Kipland.  Remember that pinging is regulated on the 'ICMP' tab of 'Firewall' - see #2 in Rulz.

    A Full NAT wouldn't work, but SNAT/DNAT could.  It's not clear to me why you're having trouble though.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • I believe this may be related to a CheckPoint Anti-spoofing rule on the far side. There was a modification required when I previously had this running through the pfSense as I was NATing a different private LAN at the time. I reached out to the engineer on the far side.

    Since this was my 1st 1:1 NAT with IPsec on a Sophos I was hoping to get some validation from the forum - and I did. Thanks, Bob. As always - you are a big help here.

  • Hi Bob,

    Just an update. I don't think there was anything wrong with the NAT configuration. It turns out that someone snaked the "fake" LAN for use with their VOIP so while I was getting packets in just fine they were routing that back to the VOIP network and not back to me. They are trying to determine yet another "fake" LAN for me to setup since they say they also use 172.16.0.0/24 on their side as well. I'll have to modify my 1:1 NATs and IPSec tunnel at that point.

    To complicate it even more they also changed the destination host and port without our knowledge so we finally got them to update their rules so that we had access to the new host only to find out the fake LAN was being re-routed on their side. They did show me clear evidence that the packets were coming across the tunnel, getting NATed correctly, and hitting the correct server but the response never got back to me.

    Now - I am assuming that whatever they pick for a fake LAN only needs to be configured on my side of the tunnel. I don't remember having them create a NAT as well on their side. We initiate the connection to them and we look like we are coming from the fake LAN so I would think that their response to my fake server request would route back out the tunnel and then we NAT it back to the real server. Im not even sure that the 2nd 1:1 NAT (Destination) is even required as they do not connect to us.

  • The Destination NAT is required, Kip, to translate their response to be to a real IP instead of a fake one.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I just wanted to follow up on this question since it turned out that there was and issue on the partner side. Apparently the "fake" IP address range was never reserved and ended up being allocated for VoIP on their side. Their routing tables had prevented any traffic from returning back through the IPsec VPN. In the end it took a lot of reconfiguration on the partner side and they eventually provided a new segment that did not require a fake IP segment - so this was just a straight forward IPsec tunnel in the end. It's up and working.

    Thanks again, Bob, for your helpful advice and guidance.