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

Reply
  • 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. 

Children
No Data