Guest User!

You are not Sophos Staff.

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

UTM9 in AWS VPC -- issues w/ipsec S2S vpns

lprikockis_01
Has anyone else had an issue where they are able to sucessfully establish an IPSEC SA between a private subnet at Amazon and an external network, but no traffic passes until traffic is initiated from the UTM/AWS side of the tunnel?

In other words, while the remote partner sees the tunnel come up successfully, if they try to ping my side of the tunnel, they get no response UNTIL I ping a host on their end of the tunnel.

After that, traffic can flow in either direction... it just seems that the remote end is unable to initiate the connection.

Not sure if it's relevant, but the remote party is using a Checkpoint firewall/vpn device.

Curious if anyone one else has run into a similar problem with the UTM9 appliance in other environments or if this is something peculiar to using it within Amazon's Virtual Private Cloud or ????

thanks


This thread was automatically locked due to age.
Parents
  • 0
    Yes, do disable all of the debugging.  In fact, that's closer to zero lines of the regular file [;)].  I think we want to look at what happened before you sent the ping; this seems to be just after.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Ok... so sometime between the beginning of this log snippet and 14:00 local time, the remote site lost the ability to send us data over the tunnel.   At about 14:10, I ping'd a host on the remote end of the tunnel and normal traffic flow resumed. 

    unfortunately, unless I'm missing something obvious, I'm not seeing anything in the log at that time that indicates what if any change took place as a result of my ping.

    For the moment, I have a cronjob that periodically pings the remote host and that seems to keep everything flowing, but it's a bit kludgy to say the least.

    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: initiating Main Mode
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: ignoring Vendor ID payload [cefb1acdf3776a874be2e8ef5137fae6ba8f15880000000e00000614]
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: received Vendor ID payload [Dead Peer Detection]
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: ignoring Vendor ID payload [HeartBeat Notify 386b0100]
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: Peer ID is ID_IPV4_ADDR: '1.1.1.1'
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: Dead Peer Detection (RFC 3706) enabled
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: ISAKMP SA established
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1}
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #2: sent QI2, IPsec SA established {ESP=>0x49ebf400 0x49ebf50f 0x49ebf650 0x49ebf7a0 0x49ebf8b2 0x49ebfa0d 
Reply
  • 0 in reply to BAlfson
    Ok... so sometime between the beginning of this log snippet and 14:00 local time, the remote site lost the ability to send us data over the tunnel.   At about 14:10, I ping'd a host on the remote end of the tunnel and normal traffic flow resumed. 

    unfortunately, unless I'm missing something obvious, I'm not seeing anything in the log at that time that indicates what if any change took place as a result of my ping.

    For the moment, I have a cronjob that periodically pings the remote host and that seems to keep everything flowing, but it's a bit kludgy to say the least.

    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: initiating Main Mode
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: ignoring Vendor ID payload [cefb1acdf3776a874be2e8ef5137fae6ba8f15880000000e00000614]
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: received Vendor ID payload [Dead Peer Detection]
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: ignoring Vendor ID payload [HeartBeat Notify 386b0100]
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: Peer ID is ID_IPV4_ADDR: '1.1.1.1'
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: Dead Peer Detection (RFC 3706) enabled
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #1: ISAKMP SA established
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1}
    2013:04:09-10:23:51 qcpfw pluto[9949]: "S_REF_IpsSitNewarkTest_0" #2: sent QI2, IPsec SA established {ESP=>0x49ebf400 0x49ebf50f 0x49ebf650 0x49ebf7a0 0x49ebf8b2 0x49ebfa0d 
Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML