Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 4543 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

Sophos UTM9 in AWS VPC <sigh>

lprikockis_01
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.
  • 0
    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.
  • 0 in reply to BrucekConvergent
    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 [:(]
  • 0 in reply to lprikockis_01
    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?
  • 0
    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)]

    Does the UTM have a public IP, or is it NATted behind another device?

    Cheers - Bob
  • 0 in reply to BAlfson
    You should start a support case with Sophos, this may be something they need to look into.
  • 0 in reply to BrucekConvergent
    Does the UTM have a public IP, or is it NATted behind another device?


    Well, it's at AWS so it has a public IP in the form of one of Amazon's EIPs... but of course, that IP is only related to the UTM instance through whatever network magic Amazon has running behind the scenes.   So I think effectively, it is indeed NAT'd behind whatever router/firewall Amazon has out front.

    You should start a support case with Sophos, this may be something they need to look into.

    Absolutely-- I did before posting this... they're still scratching their heads over this whole AWS business.  Unfortunately, it doesn't seem like anyone in support has a whole lot of experience with using this product within an Amazon VPC framework.  [:(]  

    And of course AWS support isn't of much use either because "this is a Sophos issue" ... 
  • 0
    I don't need to have NAT-T enabled to make a robust site-to-site between an instance in EC2 and the UTM in our office as both have public IPs; it works either way.  I've not played with the VPC capability, but I would expect the same would be true unless you put another UTM or VPN server instance inside the VPC Remote Network.

    Are you using VPC?

    Cheers - Bob
  • 0 in reply to BAlfson
    I don't need to have NAT-T enabled to make a robust site-to-site between an instance in EC2 and the UTM in our office as both have public IPs; 


    Thanks Bob!  That's extremely good to hear.  I am actually using VPC but as you say, it should work as long as the UTM has a public IP (which it does).

    I've actually turned off the nat-t option and verified that I am still able to establish the tunnels I had previously set up... additionally, I can now establish a working tunnel with my one troublesome client that did NOT work at all with nat-t enabled.

    So I guess the takeaway from this whole tale is that for a UTM instance configured within an AWS VPC, NAT-T is *not* required.    I think my problem was in reading some older posts that were talking about non-VPC EC2 instances (what Amazon now calls "EC2 Classic") because in that environment, AH/ES packets were definitely NOT routed, requiring the use of nat-t.

    not sure what to make of the fact that the users on this board were far more helpful than the paid support I'm getting from both Amazon and Sophos, but I sure appreciate it!

    thanks
  • 0
    not sure what to make of the fact that the users on this board were far more helpful than the paid support I'm getting from both Amazon and Sophos, but I sure appreciate it!

    I'm not familiar with Amazon's offering.  The Sophos support is more focused on Break/Fix than creating configuration solutions - it depends on resellers for that service.

    Cheers - Bob