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

How about showing us about 30 lines from the IPsec log when your ping starts the connection.

Cheers - Bob

I've probably got too much debugging info turned on here, but here's roughly the section of the log file from where I ping the remote host and "magically" everything starts working.    I'm not familiar enough with this ipsec implementation to be entirely certain what's relevant here...  I can certainly provide more detail if needed.

The point is, I'm not seeing anything (in this snippet or elsewhere) in the log that jumps out as a clear error or problem.  ???

2013:04:05-17:27:33 qcpfw pluto[4257]: |    next payload type: ISAKMP_NEXT_NONE
2013:04:05-17:27:33 qcpfw pluto[4257]: |    DOI: ISAKMP_DOI_IPSEC
2013:04:05-17:27:33 qcpfw pluto[4257]: |    protocol ID: 1
2013:04:05-17:27:33 qcpfw pluto[4257]: |    SPI size: 16
2013:04:05-17:27:33 qcpfw pluto[4257]: |    Notify Message Type: R_U_THERE
2013:04:05-17:27:33 qcpfw pluto[4257]: | emitting 8 raw bytes of notify icookie into ISAKMP Notification Payload
2013:04:05-17:27:33 qcpfw pluto[4257]: | notify icookie  fd 75 59 38  fe a5 b4 6d
2013:04:05-17:27:33 qcpfw pluto[4257]: | emitting 8 raw bytes of notify rcookie into ISAKMP Notification Payload
2013:04:05-17:27:33 qcpfw pluto[4257]: | notify rcookie  13 20 51 ea  dc a3 b0 6c
2013:04:05-17:27:33 qcpfw pluto[4257]: | emitting 4 raw bytes of notify data into ISAKMP Notification Payload
2013:04:05-17:27:33 qcpfw pluto[4257]: | notify data  00 00 65 50
2013:04:05-17:27:33 qcpfw pluto[4257]: | emitting length of ISAKMP Notification Payload: 32
2013:04:05-17:27:33 qcpfw pluto[4257]: | emitting 8 zero bytes of encryption padding into ISAKMP Message
2013:04:05-17:27:33 qcpfw pluto[4257]: | emitting length of ISAKMP Message: 92
2013:04:05-17:27:33 qcpfw pluto[4257]: | sent DPD notification R_U_THERE with seqno = 25936
2013:04:05-17:27:33 qcpfw pluto[4257]: | inserting event EVENT_DPD, timeout in 30 seconds for #1
2013:04:05-17:27:33 qcpfw pluto[4257]: | next event EVENT_DPD_UPDATE in 29 seconds for #2
2013:04:05-17:27:33 qcpfw pluto[4257]: | 
2013:04:05-17:27:33 qcpfw pluto[4257]: | *received 92 bytes from ***.***.***.***:500 on eth1
2013:04:05-17:27:33 qcpfw pluto[4257]: | **parse ISAKMP Message:
2013:04:05-17:27:33 qcpfw pluto[4257]: |    initiator cookie:
2013:04:05-17:27:33 qcpfw pluto[4257]: |   fd 75 59 38  fe a5 b4 6d
2013:04:05-17:27:33 qcpfw pluto[4257]: |    responder cookie:
2013:04:05-17:27:33 qcpfw pluto[4257]: |   13 20 51 ea  dc a3 b0 6c
2013:04:05-17:27:33 qcpfw pluto[4257]: |    next payload type: ISAKMP_NEXT_HASH
2013:04:05-17:27:33 qcpfw pluto[4257]: |    ISAKMP version: ISAKMP Version 1.0
2013:04:05-17:27:33 qcpfw pluto[4257]: |    exchange type: ISAKMP_XCHG_INFO
2013:04:05-17:27:33 qcpfw pluto[4257]: |    flags: ISAKMP_FLAG_ENCRYPTION
2013:04:05-17:27:33 qcpfw pluto[4257]: |    message ID:  de 06 89 e0
2013:04:05-17:27:33 qcpfw pluto[4257]: |    length: 92
2013:04:05-17:27:33 qcpfw pluto[4257]: | ICOOKIE:  fd 75 59 38  fe a5 b4 6d
2013:04:05-17:27:33 qcpfw pluto[4257]: | RCOOKIE:  13 20 51 ea  dc a3 b0 6c
2013:04:05-17:27:33 qcpfw pluto[4257]: | peer:  d0 44 17 fa
2013:04:05-17:27:33 qcpfw pluto[4257]: | state hash entry 17
2013:04:05-17:27:33 qcpfw pluto[4257]: | state object #1 found, in STATE_MAIN_I4
2013:04:05-17:27:33 qcpfw pluto[4257]: | ***parse ISAKMP Hash Payload:
2013:04:05-17:27:33 qcpfw pluto[4257]: |    next payload type: ISAKMP_NEXT_N
2013:04:05-17:27:33 qcpfw pluto[4257]: |    length: 24
2013:04:05-17:27:33 qcpfw pluto[4257]: | ***parse ISAKMP Notification Payload:
2013:04:05-17:27:33 qcpfw pluto[4257]: |    next payload type: ISAKMP_NEXT_NONE
2013:04:05-17:27:33 qcpfw pluto[4257]: |    length: 32
2013:04:05-17:27:33 qcpfw pluto[4257]: |    DOI: ISAKMP_DOI_IPSEC
2013:04:05-17:27:33 qcpfw pluto[4257]: |    protocol ID: 1
2013:04:05-17:27:33 qcpfw pluto[4257]: |    SPI size: 16
2013:04:05-17:27:33 qcpfw pluto[4257]: |    Notify Message Type: R_U_THERE_ACK
2013:04:05-17:27:33 qcpfw pluto[4257]: | removing 8 bytes of padding
2013:04:05-17:27:33 qcpfw pluto[4257]: | info:  fd 75 59 38  fe a5 b4 6d  13 20 51 ea  dc a3 b0 6c
2013:04:05-17:27:33 qcpfw pluto[4257]: |   00 00 65 50
2013:04:05-17:27:33 qcpfw pluto[4257]: | received DPD notification R_U_THERE_ACK with seqno = 25936
2013:04:05-17:27:33 qcpfw pluto[4257]: | next event EVENT_DPD_UPDATE in 29 seconds for #2
2013:04:05-17:27:56 qcpfw pluto[4257]: | 
2013:04:05-17:27:56 qcpfw pluto[4257]: | *received whack message
2013:04:05-17:27:56 qcpfw pluto[4257]: | next event EVENT_DPD_UPDATE in 6 seconds for #2
2013:04:05-17:28:01 qcpfw pluto[4257]: | 
2013:04:05-17:28:01 qcpfw pluto[4257]: | *received whack message
2013:04:05-17:28:01 qcpfw pluto[4257]: | next event EVENT_DPD_UPDATE in 1 seconds for #2
2013:04:05-17:28:02 qcpfw pluto[4257]: | 
2013:04:05-17:28:02 qcpfw pluto[4257]: | *time to handle event
2013:04:05-17:28:02 qcpfw pluto[4257]: | event after this is EVENT_DPD in 1 seconds
2013:04:05-17:28:02 qcpfw pluto[4257]: | inserting event EVENT_DPD_UPDATE, timeout in 30 seconds for #2
2013:04:05-17:28:02 qcpfw pluto[4257]: | next event EVENT_DPD in 1 seconds for #1
2013:04:05-17:28:03 qcpfw pluto[4257]: | 
2013:04:05-17:28:03 qcpfw pluto[4257]: | *time to handle event
2013:04:05-17:28:03 qcpfw pluto[4257]: | event after this is EVENT_DPD_UPDATE in 29 seconds
2013:04:05-17:28:03 qcpfw pluto[4257]: | recent DPD activity 2 seconds ago, no need to send DPD notification
2013:04:05-17:28:03 qcpfw pluto[4257]: | inserting event EVENT_DPD, timeout in 30 seconds for #1
2013:04:05-17:28:03 qcpfw pluto[4257]: | next event EVENT_DPD_UPDATE in 29 seconds for #2

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

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 

I wonder if the IPsec configuration in the Checkpoint takes into account that the IP on the UTM interface is different from the public IP the Checkpoint uses to reach it.

Cheers - Bob

I wonder if the IPsec configuration in the Checkpoint takes into account that the IP on the UTM interface is different from the public IP the Checkpoint uses to reach it.

Cheers - Bob

Perhaps... I don't have as easy access to the network guy on the other end of this tunnel as I'd like.  Was hoping to be able to solve this from my end, but it's looking increasingly likely that S2S VPNs with Checkpoint are going to be an extra PITA.

if you like, we'd be happy to help you in replacing those checkpoints [;)]

It might be possible to do this at the command line.  You might want to vote for coewar's suggestion: Expand ipsec.conf control to webadmin

Cheers - Bob

very interesting... so in other words, if I were to modify ipsec.conf to include 

left="1.1.1.1" (where 1.1.1.1 would be the EIP for my UTM device)

instead of what it currently gets set to:  left="172.25.151.254"

that might make Mr. Checkpoint more willing to talk to me.   Alternatively, it sounds like I'd have to have the guy at the other end set the vpn_id for my side to the 172.25.151.254 address.

It definitely would be nice to see the ability to configure these sorts of settings thru the web GUI.

thanks for all the help.  I feel like I at least have a better handle on what's going on here.

If I've understood correctly (never have tried this)...

Since this would be true for all IPsec tunnels for your situation, I think you can add the line to ipsec.conf-default (also in /var/sec/chroot-ipsec/etc) and that your changes will surive Up2Dates and will be included in backups.

Cheers - Bob