PIX Ipsec VPN - SA established, no traffic passes

Late last night I noticed when I got home I had no access to my office, although both sides indicated that the tunnel was up. Today the problem persists where I have an established tunnel, but no traffic passes. I would like to say this is an issue with the config, but the VPN has been working for some time now. This is just out of the blue that no traffic passes. The other end is Linux/Openswan. Both sides debug shows nothing of interest at least from what I can see

I have now spend a lot of time re-starting the connection in hopes the tunnel will just magically re-open so to speak with no luck. In the past I have encountered this issue with Openswan where I simply just needed to restart ipsec on and everything would be fine in a matter seconds. Now however this tunnel just does not want to re-open. Any help will be very much appreciated

PIX506# show crypto ipsec sa interface: outside Crypto map tag: dyn-map, local addr. 6x.xxx.xxx.xx local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0) current_peer: 7x.xx.xxx.xxx:500 PERMIT, flags={} #pkts encaps: 15, #pkts encrypt: 15, #pkts digest 15 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 6x.xxx.xxx.xx, remote crypto endpt.:

7x.xx.xxx.xxx path mtu 1500, ipsec overhead 72, media mtu 1500 current outbound spi: 60d76870 inbound esp sas: spi: 0x346bc9b5(879479221) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: dyn-map sa timing: remaining key lifetime (k/sec): (4608000/86045) IV size: 16 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x60d76870(1624729712) transform: esp-aes-256 esp-sha-hmac , in use settings ={Tunnel, } slot: 0, conn id: 1, crypto map: dyn-map sa timing: remaining key lifetime (k/sec): (4607998/86045) IV size: 16 bytes replay detection support: Y outbound ah sas: outbound pcp sas: interface: inside Crypto map tag: inside_map, local addr. 192.168.1.1 PIX506#

This is what Openswan reports in the log: May 3 13:28:18 EFW pluto[3733]: "CiscoPIX" #17: initiating Main Mode May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: STATE_MAIN_I2: sent MI2, expecting MR2 May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: received Vendor ID payload [XAUTH] May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: received Vendor ID payload [Dead Peer Detection] May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: received Vendor ID payload [Cisco-Unity] May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: ignoring unknown Vendor ID payload [16bf097638a31d3aa6e82a198224b924] May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: I did not send a certificate because I do not have one. May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: STATE_MAIN_I3: sent MI3, expecting MR3 May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: Main mode peer ID is ID_IPV4_ADDR: '6x.xxx.xxx.xx' May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024} May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: Dead Peer Detection (RFC 3706): enabled May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #18: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#17} May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: ignoring informational payload, type IPSEC_INITIAL_CONTACT May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #17: received and ignored informational message May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #18: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #18: Dead Peer Detection (RFC 3706): enabled May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #18: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2 May 3 13:28:19 EFW pluto[3733]: "CiscoPIX" #18: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x18dd0900 0x7255006a

Reply to
George A.
Loading thread data ...

George, I have never worked with Openswan but I do have a bit of experience with Cisco tunnels (EZVPN, L2L). You said that the tunnels appear to be up, do you have no nat acls in place for the tunnel. On your crypto sa it shows that there are a couple encaps (15 you must have rebooted recently) and no decaps, this means the Cisco is not receiving anything from the tunnel.

Reply to
Steven B

Thanks for replying. To tell you the truth I am begining to have doubts about Openswan. Just completely out of the blue, it started working again. The problem is both sides, either PIX debug or Openswan logs indicated nothing, it is if the device I am trying to ping or access has been turned off. I know this not to be the case though.

There are no NAT issues, simply because NAT has been disabled, besides you would think if it was any issue such as that, I would have experienced this from the start. Instead the VPN works great for a week, then abruptly these problems occur. Then for no logical reason the VPN works, all the while both sides indicate that the tunnel is fine. I did reboot the firewall out of frustration and hopes that maybe that could do the trick. My previous setup a long time ago was using m0n0wall (FreeBSD) where if I deleted the SAs on my side, I had to actually reboot the PIX in order to re-establish them. Can not explain that one, but it worked like a charm, and this setup was actually quite stable.

Reply to
George A.

Hmmm... Have you tried establishing the tunnel from either side? I notice a gotcha on our system (IOS to IOS VPN) where one of our subnets works good, but the secondary subnet does not. If the tunnel expires and they try and establish from the remote location, the SA comes up but no packets will travel. If we then try and send packets from the HQ to the BO, the SA will reconstruct itself and everything will be fine. I just set a cron job on one of our HQ unix servers to periodically ping the BO to make sure the tunnel stays established

*from* our HQ.
Reply to
Mikhael47

Well very annoyingly, and without seemingly doing anything, the tunnel came back up and has been operational without issues since. Even more it just seemed to come back on it's own. I left it alone for a few hours and when I came back saw it was established.

Reply to
George A.

If it's over the internet, I've seen issues where ISPs block IPSEC traffic on "consumer" type accounts ... why?? Because they want to sell you a "business internet" package.

Reply to
Mikhael47

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.