Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
506 Views 2 Replies Latest reply: Aug 28, 2013 2:11 PM by dpbpc62 RSS
dpbpc62 Apprentice 82 posts since
Aug 29, 2011
Currently Being Moderated

Aug 21, 2013 8:28 AM

VPN SA fails MFE v8.3.1

OK, now I'm getting no SA errors, the VPN tunnel goes idle, you can connect to any devices, no traffic goes thru the tunnel but the tunnel stays up.

I turned on force rekey in the VPN definition, and made sure the key lifetimes for phase 1 and phase 2 are the same in both the vpn client (shrewsoft) and vpn definition which are 3600 and 700.

 

Not sure what to do, other then lower in the key lifetimes. The tunnel stays up passing traffic for about an hour then the SA dies.

 

2013-08-20 16:04:51 -0400 f_system a_hmon t_lcm p_minor
pid: 4980 logid: 0 cmd: 'monitord' hostname: domain.com
mbuf_data: 10 cpu_data: 0 real_data: 84 load_data: 0 virt_data: 52
ipkt: 847 opkt: 780 ibytes: 155504 obytes: 289203
-----------------
2013-08-20 16:04:50 -0400 f_kernel_ipsec a_vpn t_error p_minor
hostname: domain.com event: IPsec input no SA src_geo: CA
srcip: x.x.x.x srczone: external dst_geo: CA dstip: x.x.x.x
interface: 1-0 spi: 0x3d3a99f seq_num: 1638
information: ipsec:input_no_sa:1
reason: Received an IPsec packet for which there was no valid security association.  This is probably the result of a synchronization issue with the remote VPN peer.
-----------------
2013-08-20 16:04:49 -0400 f_kernel_ipsec a_vpn t_error p_minor
hostname: domain.com event: IPsec input no SA src_geo: CA
srcip: x.x.x.x srczone: external dst_geo: CA dstip: x.x.x.x
interface: 1-0 spi: 0x3d3a99f seq_num: 1637
information: ipsec:input_no_sa:1
reason: Received an IPsec packet for which there was no valid security association.  This is probably the result of a synchronization issue with the remote VPN peer.
-----------------
2013-08-20 16:04:47 -0400 f_isakmp_daemon a_vpn t_error p_major
pid: 4986 logid: 0 cmd: 'ikmpd' hostname: domain.com
cky_i: 7f29d1ff5a632f5e cky_r: c9951a9346727bf5 msg_id: 3e39469c
local_gw: x.x.x.x remote_gw: x.x.x.x
information: [detailed info]
[error]
   QUICK_MODE exchange processing failed  [error]
   invalid request for QUICK_MODE exchange, no IKE SA exists which
matches request
-----------------
2013-08-20 16:04:47 -0400 f_isakmp_daemon a_vpn t_debug p_minor
pid: 4986 logid: 0 cmd: 'ikmpd' hostname: domain.com
information: ##### - in process_error_queue
-----------------
2013-08-20 16:04:47 -0400 f_isakmp_daemon a_vpn t_debug p_minor
pid: 4986 logid: 0 cmd: 'ikmpd' hostname: domain.com
information: ##### - in exchange_error
-----------------
2013-08-20 16:04:47 -0400 f_isakmp_daemon a_vpn t_debug p_minor
pid: 4986 logid: 0 cmd: 'ikmpd' hostname: domain.com
information: ##### - in udp_read
-----------------
2013-08-20 16:04:45 -0400 f_kernel_ipsec a_vpn t_error p_minor
hostname: domain.com event: IPsec input no SA src_geo: CA
srcip: x.x.x.x srczone: external dst_geo: CA dstip: x.x.x.x
interface: 1-0 spi: 0x3d3a99f seq_num: 1636
information: ipsec:input_no_sa:1
reason: Received an IPsec packet for which there was no valid security association.  This is probably the result of a synchronization issue with the remote VPN peer.
-----------------
2013-08-20 16:04:42 -0400 f_isakmp_daemon a_vpn t_error p_major
pid: 4986 logid: 0 cmd: 'ikmpd' hostname: domain.com
cky_i: 7f29d1ff5a632f5e cky_r: c9951a9346727bf5 msg_id: 3e39469c
local_gw: x.x.x.x remote_gw: x.x.x.x
information: [detailed info]
[error]
   QUICK_MODE exchange processing failed  [error]
   invalid request for QUICK_MODE exchange, no IKE SA exists which
matches request

  • mtuma McAfee SME 314 posts since
    Nov 3, 2009
    Currently Being Moderated
    1. Aug 21, 2013 8:34 AM (in response to dpbpc62)
    Re: VPN SA fails MFE v8.3.1

    A general recommendation that I have for client VPNs is to have the client re-negotiate the tunnel first. This is accomplished by setting the rekey times on the client lower than the Firewall. If the client is behind a NAT device and the firewall attempts the renegotiation first, the renegotiation packets from the firewall may not get through to the client.

     

    Hope this helps.

     

    -Matt

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points