Guest User!

You are not Sophos Staff.

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

Sophos UTM9 in AWS VPC <sigh>

I feel like us AWS/UTM users need our own support group sometimes...

anyway-- a hopefully simple question:

For setting up IPSec site-to-site tunnels to servers within a private subnet of a VPC, is it always necessary to have NAT-T enabled in order for the the IPSec traffic to get routed through Amazon's network infrastructure correctly?

I've gotten conflicting answers from AWS on this and my own experience has been equally mixed.  I have several tunnels that SEEM to work ok with NAT-T disabled, but at least one that absolutely will not come up unless it's DISABLED on both sides.    In other cases, traffic seems to get routed properly only if it's ENABLED.

Since this is apparently a global setting on the UTM, I'm in a bit of a pickle.  Anyone with any experience/success stories in this area?


This thread was automatically locked due to age.
Parents
  • I always leave NAT-T enabled; given how AWS provisions public IPs, it's how it should be set.  The issue is, however, that some other vendors do not implement NAT-T correctly (older Watchguard boxes come to mind), so then you're caught in a catch-22.
  • ok... good to know.   Interestingly, the partner I'm currently having trouble with is using Cisco gear (ASA I believe).    For whatever reason, he can't / won't enable nat-traversal and I can't seem to get the tunnel to come up with it enabled on my end [:(]
Reply
  • ok... good to know.   Interestingly, the partner I'm currently having trouble with is using Cisco gear (ASA I believe).    For whatever reason, he can't / won't enable nat-traversal and I can't seem to get the tunnel to come up with it enabled on my end [:(]
Children
  • so *with* NAT-T turned on, attempting to connect to this one Cisco ASA-based VPN results in the following:

    2013:06:13-09:49:11 qcpfw pluto[4917]: added connection description "S_*** ****** (ABC)"
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: initiating Main Mode
    2013:06:13-09:49:11 qcpfw pluto[4917]: added connection description "S_*** ****** (ABC)"
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: enabling possible NAT-traversal with method RFC 3947
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: ignoring Vendor ID payload [Cisco-Unity]
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: received Vendor ID payload [Dead Peer Detection]
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: ignoring Vendor ID payload [ef3d7f6a9e082e510a23c83c19e4cc01]
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: received Vendor ID payload [XAUTH]
    2013:06:13-09:49:11 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
    2013:06:13-09:49:11 qcpfw pluto[4917]: ERROR: asynchronous network error report on eth1 for message to 1.1.1.1 port 4500, complainant 1.1.1.1: No route to host [errno 113, origin ICMP type 3 code 13 (not authenticated)] 
    2013:06:13-09:49:14 qcpfw pluto[4917]: packet from 1.1.1.1:500: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
    2013:06:13-09:49:14 qcpfw pluto[4917]: packet from 1.1.1.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    2013:06:13-09:49:14 qcpfw pluto[4917]: packet from 1.1.1.1:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: responding to Main Mode
    2013:06:13-09:49:14 qcpfw pluto[4917]: | NAT-T: new mapping 1.1.1.1:4500/500)
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: ignoring Vendor ID payload [Cisco-Unity]
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: received Vendor ID payload [Dead Peer Detection]
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: ignoring Vendor ID payload [e6b432fdaecdd08251d63e753e5894c9]
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: received Vendor ID payload [XAUTH]
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
    2013:06:13-09:49:14 qcpfw pluto[4917]: packet from 1.1.1.1:4500: Main Mode message is part of an unknown exchange
    2013:06:13-09:49:14 qcpfw pluto[4917]: | protocol/port in Phase 1 ID Payload is 17/0. accepted with port_floating NAT-T
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: Peer ID is ID_IPV4_ADDR: '1.1.1.1'
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: Dead Peer Detection (RFC 3706) enabled
    2013:06:13-09:49:14 qcpfw pluto[4917]: | NAT-T: new mapping 1.1.1.1:500/4500)
    2013:06:13-09:49:14 qcpfw pluto[4917]: "S_*** ****** (ABC)" #38: sent MR3, ISAKMP SA established
    2013:06:13-09:49:14 qcpfw pluto[4917]: ERROR: asynchronous network error report on eth1 for message to 1.1.1.1 port 4500, complainant 1.1.1.1: No route to host [errno 113, origin ICMP type 3 code 13 (not authenticated)] 
    2013:06:13-09:49:21 qcpfw pluto[4917]: "S_*** ****** (ABC)" #37: discarding duplicate packet; already STATE_MAIN_I3
    2013:06:13-09:49:21 qcpfw pluto[4917]: ERROR: asynchronous network error report on eth1 for message to 1.1.1.1 port 4500, complainant 1.1.1.1: No route to host [errno 113, origin ICMP type 3 code 13 (not authenticated)] 
    2013:06:13-09:49:24 qcpfw pluto[4917]: packet from 1.1.1.1:4500: Main Mode message is part of an unknown exchange 

    Can anyone more familiar with Strongswan's logging glean any useful hints about what's wrong from this exchange?