Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 3 subscribers
  • Views 2013 views
  • Users 0 members are here
Options
Suggested
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

NAT private IP to private IP over IPsec tunnel

JerDub21

First of all, thank you for your patience as I am new to the Sophos UTM world.

We have a Sophos UTM 9 that is making an IPsec connection to a customer's network. We need to NAT a single IP on our local end of the connection to avoid an IP conflict on their end. Here are some details.

The remote Gateway has been defined as well as a few remote networks

10.3.1.0/24

10.3.2.0/24

10.4.0.0/16

Our local interface is in place and our local network has been configured

192.168.110.0/24 (This network does not exist in our environment and is where the NAT comes into play)

Keys shared, policies match, the SA's establish without problems.

Now,

What I'm trying to do is NAT 192.168.110.10/32 (does not exist) to our actual server interface with an IP of 10.200.110.10

I've tried creating a DNAT, a DNAT and a SNAT, a 1:1 NAT. I've tried creating an interface for 192.168.110.10 (which actually will respond to a ping from the customer's side) and setting up the NAT using that interface as opposed to network, but I cannot get any communication from their remote networks to our 10.200.110.10 server. Automatically created firewall rules have been used in every scenario. The logs don't seem to show any ICMP traffic at all when I'm testing (i've heard that's just a "Sophos thing" and it's not possible to do??). I've tried instruction from another post here to view a tcpdump but the results come out unreadable (i think resolving this will be my next step going forward). Is there static routing that's required for this? I figured the VPN would handle that.

I'm sure I'm just missing something dumb since I'm not familiar with the WebAdmin interface. It seems straightforward enough but I sure can't get it to work. 

Any insights would be greatly appreciated.

Thanks!



This thread was automatically locked due to age.
Parents
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to Sophos Community.

    Assuming you have configured IPSec tunnel with below local and remote networks.

    Local networks:
    192.168.110.0/24

    Remote networks:
    10.3.1.0/24
    10.3.2.0/24
    10.4.0.0/16

    JerDub21 said:
    What I'm trying to do is NAT 192.168.110.10/32 (does not exist) to our actual server interface with an IP of 10.200.110.10

    To achieve this you need 1:1 NAT rule as shown below:

    Use the below command to check ICMP packet flow coming from the remote network.

    utm:/root # tcpdump -nei any host <remote location IP> and proto ICMP

    eg: utm:/root # tcpdump -nei any host 10.3.1.1 and proto ICMP

Reply
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to Sophos Community.

    Assuming you have configured IPSec tunnel with below local and remote networks.

    Local networks:
    192.168.110.0/24

    Remote networks:
    10.3.1.0/24
    10.3.2.0/24
    10.4.0.0/16

    JerDub21 said:
    What I'm trying to do is NAT 192.168.110.10/32 (does not exist) to our actual server interface with an IP of 10.200.110.10

    To achieve this you need 1:1 NAT rule as shown below:

    Use the below command to check ICMP packet flow coming from the remote network.

    utm:/root # tcpdump -nei any host <remote location IP> and proto ICMP

    eg: utm:/root # tcpdump -nei any host 10.3.1.1 and proto ICMP

Children
  • 0 in reply to FormerMember

    Yash,

    Thank you for your response, I very much appreciate it. 

    I have configured the 1:1 NAT per your recommendation using /32 addresses for the NAT and Local addresses.

    The result of the tcpdump shows successful translation coming in but no translation going out resulting in an unsuccessful ping

    15:08:03.842130  In ethertype IPv4 (0x0800), length 100: 10.3.1.1 > 192.168.118.10: ICMP echo request, id 40350, seq 793, length 64
15:08:03.842215 Out ethertype IPv4 (0x0800), length 100: 10.3.1.1 > 10.200.110.10: ICMP echo request, id 40350, seq 793, length 64
15:08:03.842218 Out ethertype Unknown (0x0028), length 104:
        0x0000:  0000 0800 4500 0054 fe1d 4000 3b01 29c0  ....E..T..@.;.).
        0x0010:  0a03 01f1 0ac8 0110 0800 7caa 9d9e 0319  ..........|.....
        0x0020:  33ed 9260 0000 0000 4c7d 0900 0000 0000  3..`....L}......
        0x0030:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f  ................
        0x0040:  2021 2223 2425 2627 2829 2a2b 2c2d 2e2f  .!"#$%&'()*+,-./
        0x0050:  3031 3233 3435 3637                      01234567

    Would I need to make another 1:1 NAT going the "opposite" direction? Something like this?

    For traffic from: Local /32

    Going to: Remote /32

    Map destination

    Map to: NAT /32

    Thanks again.

  • FormerMember
    +1 FormerMember in reply to JerDub21
    JerDub21 said:
    Would I need to make another 1:1 NAT going the "opposite" direction? Something like this?

    No additional 1:1 NAT would be required.

    As per the packet flow, traffic destined to 192.168.118.10 is being NATed to 10.200.110.10 by Sophos UTM.

    15:08:03.842130 In ethertype IPv4 (0x0800), length 100: 10.3.1.1 > 192.168.118.10: ICMP echo request, id 40350, seq 793, length 64
    15:08:03.842215 Out ethertype IPv4 (0x0800), length 100: 10.3.1.1 > 10.200.110.10: ICMP echo request, id 40350, seq 793, length 64

    ICMP request is sent out to 10.200.110.10, but there is no ICMP reply coming back.

    Please ensure that 10.200.110.10 responds to ICMP requests. If it does then I'd request to run Wireshark on 10.200.110.10 to check if it responds to ICMP requests coming from 10.3.1.1 IP.

    In Wireshark, you can apply a filter as shown in the below snapshot.

  • 0 in reply to FormerMember

    Yash,

    Thank you for your assistance. You were correct, SElinux running on the local host in question (a specialized "canned" IBM product) was causing the ICMP echo to fail. The vendor was able to resolve the issue and all is well now. Kudos to you, Sir!

  • FormerMember
    0 FormerMember in reply to JerDub21

    Glad to know that an issue is resolved now.

Unfiltered HTML