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

IPSec Roadwarrior hanging

bdsthai
ASL 4.015 with a IPSec Roadwarrior using AES policy and PSK with SSH Sentinel 1.4 is generally working well. However, sometimes users are not able to connect. When this happens, simply toggling this IPSec connection off and on allows users to connect again. The information that I have been able to get out of my users is that this seems to happen if they do not gracefully disconnect from the established VPN connection (ie: computer goes into standby and when it comes out it has lost the VPN connection, or a user shut down their PC before disconnecting from the VPN, or even a hung PC that requires a restart). Obviously the best thing would be for a user to properly disconnect everytime, but this doesn't always happen in the real world.

When looking at the VPN connections after a user has complained that they can no longer connect (at this point they definitely do NOT have an existing connection) I see that ASL is reporting a VPN connection.

Can anyone explain what ASL does with a IPSec Roadwarrior connection that is not properly disconnected from SSH Sentinel?

Here is sample of the log file:

2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [SSH Sentinel 1.4]
2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2003-Oct 29 09:44:09 (none) pluto[24244]: "AES_1"[8] 203.155.94.157 #132: responding to Main Mode from unknown peer 203.155.94.157
2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [SSH Sentinel 1.4]
2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
2003-Oct 29 09:44:09 (none) pluto[24244]: packet from 203.155.94.157:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2003-Oct 29 09:44:09 (none) pluto[24244]: "AES_1"[8] 203.155.94.157 #133: responding to Main Mode from unknown peer 203.155.94.157
2003-Oct 29 09:44:10 (none) pluto[24244]: "AES_1"[8] 203.155.94.157 #132: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-00/01: peer is NATed
2003-Oct 29 09:44:10 (none) pluto[24244]: "AES_1"[8] 203.155.94.157 #132: Warning: peer is NATed but source port is still udp/500. Ipsec-passthrough NAT device suspected -- NAT-T may not work.
2003-Oct 29 09:44:11 (none) pluto[24244]: "AES_1"[8] 203.155.94.157 #132: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2003-Oct 29 09:44:11 (none) pluto[24244]: "AES_1"[8] 203.155.94.157 #132: Main mode peer ID is ID_IPV4_ADDR: '10.100.35.36'
2003-Oct 29 09:44:11 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: sent MR3, ISAKMP SA established
2003-Oct 29 09:44:12 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: Virtual IP 192.168.105.105/32 is already used by '10.100.33.58'
2003-Oct 29 09:44:12 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: Your ID is '10.100.35.36'
2003-Oct 29 09:44:12 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: Virtual IP 192.168.105.105/32 is already used by '10.100.33.58'
2003-Oct 29 09:44:12 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: Your ID is '10.100.35.36'
2003-Oct 29 09:44:12 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: cannot respond to IPsec SA request because no connection is known for 192.168.110.0/24===203.121.182.200...203.155.94.157[10.100.35.36]===192.168.105.105/32
2003-Oct 29 09:44:12 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: sending encrypted notification INVALID_ID_INFORMATION to 203.155.94.157:500
2003-Oct 29 09:44:13 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xa28a5a29 (perhaps this is a duplicated packet)
2003-Oct 29 09:44:13 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #132: sending encrypted notification INVALID_MESSAGE_ID to 203.155.94.157:500
2003-Oct 29 09:45:19 (none) pluto[24244]: "AES_1"[8] 203.155.94.157 #133: max number of retransmissions (2) reached STATE_MAIN_R1
2003-Oct 29 09:45:54 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [SSH Sentinel 1.4]
2003-Oct 29 09:45:54 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
2003-Oct 29 09:45:54 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
2003-Oct 29 09:45:54 (none) pluto[24244]: packet from 203.155.94.157:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2003-Oct 29 09:45:54 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: responding to Main Mode from unknown peer 203.155.94.157
2003-Oct 29 09:45:54 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [SSH Sentinel 1.4]
2003-Oct 29 09:45:54 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
2003-Oct 29 09:45:55 (none) pluto[24244]: packet from 203.155.94.157:500: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
2003-Oct 29 09:45:55 (none) pluto[24244]: packet from 203.155.94.157:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2003-Oct 29 09:45:55 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #135: responding to Main Mode from unknown peer 203.155.94.157
2003-Oct 29 09:45:55 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-00/01: peer is NATed
2003-Oct 29 09:45:55 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: Warning: peer is NATed but source port is still udp/500. Ipsec-passthrough NAT device suspected -- NAT-T may not work.
2003-Oct 29 09:45:56 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2003-Oct 29 09:45:56 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: Main mode peer ID is ID_IPV4_ADDR: '10.100.35.36'
2003-Oct 29 09:45:56 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: sent MR3, ISAKMP SA established
2003-Oct 29 09:45:57 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: Virtual IP 192.168.105.105/32 is already used by '10.100.33.58'
2003-Oct 29 09:45:57 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: Your ID is '10.100.35.36'
2003-Oct 29 09:45:57 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: Virtual IP 192.168.105.105/32 is already used by '10.100.33.58'
2003-Oct 29 09:45:57 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: Your ID is '10.100.35.36'
2003-Oct 29 09:45:57 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: cannot respond to IPsec SA request because no connection is known for 192.168.110.0/24===203.121.182.200...203.155.94.157[10.100.35.36]===192.168.105.105/32
2003-Oct 29 09:45:57 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: sending encrypted notification INVALID_ID_INFORMATION to 203.155.94.157:500




This thread was automatically locked due to age.
Parents
  • 0
    the only problem I find in this log is:

    2003-Oct 29 09:45:55 (none) pluto[24244]: "AES_1"[9] 203.155.94.157 #134: Warning: peer is NATed but source port is still udp/500. Ipsec-passthrough NAT device suspected -- NAT-T may not work. 

    which indicates that the client is behind some device doing IPSEC passthrough, this and NAT-T do not go along, therefore you have to turn NAT-T in SSH Sentinel off in this case or stop the device doing IPSEC passthrough. 
  • 0 in reply to Andy_01
    Hi Andy,

    Thanks for the suggestion. We turned off NAT-T in SSH Sentinel  (we do not have control of the device that is doing IPSEC passthrough). However, the same symptoms and problem still exists. Any other suggestions?

    Rgds,
    bdsthai   
Reply
  • 0 in reply to Andy_01
    Hi Andy,

    Thanks for the suggestion. We turned off NAT-T in SSH Sentinel  (we do not have control of the device that is doing IPSEC passthrough). However, the same symptoms and problem still exists. Any other suggestions?

    Rgds,
    bdsthai   
Children
  • 0 in reply to bdsthai
    hi bdsthai,

    you could change the lifetime to a low value. Then the maximum time the client has to wait is that lifetime.
    Make also sure the vIP-Setting in SSH-Sentinel does not have a 32Bit Subnetmask. Use a 24Bit Subnetmask instead.

    Cheers
    Xeno  
Cookie Information Banner