IPSEC Tunnel comes up only after PING

vbankar · ‎02-08-2010

Hi,

I have a L2L IPSEC and it looks like whenever I try to open remote LAN sites from the browser, it doesn't open. When I ping, the first ping times out and then it starts working. Then if I try to open the sites from browser, everything opens fine.

My question is - why does the tunnel comes up only after PING, ideally any traffic should be able to wake the ipsec, right?

How can I enable ipsec enabling with port 80 traffic..?

Jon Marshall · ‎02-08-2010

vbankar wrote:

Hi,

I have a L2L IPSEC and it looks like whenever I try to open remote LAN sites from the browser, it doesn't open. When I ping, the first ping times out and then it starts working. Then if I try to open the sites from browser, everything opens fine.

My question is - why does the tunnel comes up only after PING, ideally any traffic should be able to wake the ipsec, right?

How can I enable ipsec enabling with port 80 traffic..?

The tunnel should come up when you use your browser as long as you have included that in the interesting traffic but i'm guessing your crypto map acl says "permit ip ...." so that should cover http.

As you can see there is a delay when setting up an IPSEC tunnel ie. the first ping times out. Have you tried refreshing the web page a couple of times ?

Jon

vbankar · ‎02-08-2010

Actually I even refreshed many times earlier also but its not getting initiated. The interesting traffic mentions permit ip...

Any clues still.. ?

Farrukh Haroon · ‎02-09-2010

Can you post the related config? (VPN, ACL, Pool, NAT 0 etc.)

Regards

Farrukh

vbankar · ‎02-12-2010

C:\Documents and Settings>ping 194.39.88.108

Pinging 194.39.88.108 with 32 bytes of data:

Request timed out.
Reply from 194.39.88.108: bytes=32 time=175ms TTL=127
Reply from 194.39.88.108: bytes=32 time=175ms TTL=127
Reply from 194.39.88.108: bytes=32 time=174ms TTL=127

Ping statistics for 194.39.88.108:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 174ms, Maximum = 175ms, Average = 174ms

Remote endpoint: 194.76.49.28
Remote lan: 194.39.88.108

Local endpoint: 209.243.128.3
Local lan: 209.243.128.x

CONFIGURATION:

crypto map taectunnel 11 match address 110
crypto map taectunnel 11 set peer 194.76.49.28
crypto map taectunnel 11 set transform-set tee
crypto map taectunnel interface outside

crypto ipsec transform-set tee esp-3des esp-md5-hmac
crypto map taectunnel 11 set transform-set tee

access-list 110 extended permit ip 209.243.128.0 255.255.192.0 172.27.72.0 255.255.255.0
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 192.109.151.128 255.255.255.128
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 192.109.152.0 255.255.252.0
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 192.109.156.0 255.255.255.0
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 192.109.157.0 255.255.255.0
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 194.39.88.0 255.255.252.0
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 194.39.93.0 255.255.255.0
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 194.39.94.0 255.255.255.0
access-list 110 extended permit ip 209.243.128.0 255.255.192.0 194.76.51.0 255.255.255.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 172.27.72.0 255.255.255.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 192.109.151.128 255.255.255.128
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 192.109.152.0 255.255.252.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 192.109.156.0 255.255.255.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 192.109.157.0 255.255.255.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 194.39.88.0 255.255.252.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 194.39.93.0 255.255.255.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 194.39.94.0 255.255.255.0
access-list 110 extended permit ip 204.162.153.0 255.255.255.0 194.76.51.0 255.255.255.0

sh crypto isakmp sa det

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1   IKE Peer: 194.76.49.28
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE
    Encrypt : 3des            Hash    : MD5
    Auth    : preshared       Lifetime: 86400
    Lifetime Remaining: 86097

sh crypto ipsec sa

interface: outside
Crypto map tag: taectunnel, seq num: 11, local addr: 209.243.128.3

      access-list 110 permit ip 209.243.128.0 255.255.192.0 194.39.88.0 255.255.252.0
      local ident (addr/mask/prot/port): (209.243.128.0/255.255.192.0/0/0)
      remote ident (addr/mask/prot/port): (194.39.88.0/255.255.252.0/0/0)
      current_peer: 194.76.49.28

      #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
      #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 10, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

local crypto endpt.: 209.243.128.3, remote crypto endpt.: 194.76.49.28

      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: C85C3667
      current inbound spi : 3A235B51

    inbound esp sas:
      spi: 0x3A235B51 (975395665)
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 3174400, crypto-map: taectunnel
         sa timing: remaining key lifetime (kB/sec): (4373999/28380)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000003
    outbound esp sas:
      spi: 0xC85C3667 (3361486439)
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 3174400, crypto-map: taectunnel
         sa timing: remaining key lifetime (kB/sec): (4373999/28380)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

Crypto map tag: taectunnel, seq num: 11, local addr: 209.243.128.3

      access-list 110 permit ip 209.243.128.0 255.255.192.0 194.39.88.0 255.255.252.0
      local ident (addr/mask/prot/port): (209.243.132.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (194.39.88.0/255.255.252.0/0/0)
      current_peer: 194.76.49.28

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

local crypto endpt.: 209.243.128.3, remote crypto endpt.: 194.76.49.28

      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: 3970EFD4
      current inbound spi : ED22E50A

    inbound esp sas:
      spi: 0xED22E50A (3978487050)
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 3174400, crypto-map: taectunnel
         sa timing: remaining key lifetime (kB/sec): (4373999/28603)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x0000000F
    outbound esp sas:
      spi: 0x3970EFD4 (963702740)
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 3174400, crypto-map: taectunnel
         sa timing: remaining key lifetime (kB/sec): (4374000/28602)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

Farrukh Haroon · ‎02-12-2010

Which platform is this? PIX 6.x? What software version are you running (exactly).

Also are you using the same ACL for crypto and NAT-0 or are they different?

I would appreciate if you could clear the VPN tunnels, and then capture IPSEC debugs in both of these conditions:

> Clear Phase 1 and 2, and then generate ICMP traffic

> Clear Phase 1 and 2, and then generate non-ICMP traffic

Regards

Farrukh

vbankar · ‎02-16-2010

Device is ASA5520, Version 8.0(4)39

Nat 0 is on different ACL. This is the nat 0 config:

nat (inside) 0 access-list 120
access-list 120 extended permit ip 209.243.128.0 255.255.192.0 194.39.88.0 255.255.252.0
access-list 120 extended permit ip 209.243.128.0 255.255.192.0 194.39.93.0 255.255.255.0
access-list 120 extended permit ip 209.243.128.0 255.255.192.0 194.39.94.0 255.255.255.0
access-list 120 extended permit ip 209.243.128.0 255.255.192.0 194.76.51.0 255.255.255.0

Did following debugs:

debug crypto isakmp 200
debug crypto ipsec 200
debug crypto engine 200

After clearing ipsec sas, no debugs are getting generated for ipsec or isakmp for both icmp or non-icmp traffic.

An FYI - After clearing, the SAs establish in few minutes fine. The only thing happening is the ICMP traffic helps generate non-ICMP traffic flow. And after few mins if I don't use the non-ICMP traffic, again I have to ping and make the non-icmp traffic flow.

I could see this debug after few hrs though:

Feb 16 13:00:30 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, processing hash payload
Feb 16 13:00:30 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, processing notify payload
Feb 16 13:00:30 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, Received keep-alive of type DPD R-U-THERE (seq number 0x456991b2)
Feb 16 13:00:30 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, Sending keep-alive of type DPD R-U-THERE-ACK (seq number 0x456991b2)
Feb 16 13:00:30 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, constructing blank hash payload
Feb 16 13:00:30 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, constructing qm hash payload
Feb 16 13:00:30 [IKEv1]: IP = 194.76.49.28, IKE_DECODE SENDING Message (msgid=6f4525d6) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 80
Feb 16 13:00:40 [IKEv1]: IP = 194.76.49.28, IKE_DECODE RECEIVED Message (msgid=afd1ba03) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 80
Feb 16 13:00:40 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, processing hash payload
Feb 16 13:00:40 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, processing notify payload
Feb 16 13:00:40 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, Received keep-alive of type DPD R-U-THERE (seq number 0x456991b3)
Feb 16 13:00:40 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, Sending keep-alive of type DPD R-U-THERE-ACK (seq number 0x456991b3)
Feb 16 13:00:40 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, constructing blank hash payload
Feb 16 13:00:40 [IKEv1 DEBUG]: Group = 194.76.49.28, IP = 194.76.49.28, constructing qm hash payload
Feb 16 13:00:40 [IKEv1]: IP = 194.76.49.28, IKE_DECODE SENDING Message (msgid=605ee23a) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 80
Feb 16 13:00:50 [IKEv1]: IP = 194.76.49.28, IKE_DECODE RECEIVED Message (msgid=e0cdf8ca) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 80

timothybward · ‎02-17-2010

Ive seen people suggesting that you set up a sla montior to send pings down the tunnel. Would that work to keep it up?

zvondovec · ‎02-17-2010

hi,

how about try this : isakmp keepalive threshold 60 retry 2 ?

bye

vbankar · ‎02-18-2010

I tried that also:

tunnel-group 194.76.49.28 type ipsec-l2l
tunnel-group 194.76.49.28 ipsec-attributes
pre-shared-key *
isakmp keepalive threshold 3600 retry 2

There is another command configured:

no crypto isakmp nat-traversal

INITIAL OUTPUT BEFORE GENERATING ANY TRAFFIC:

      #pkts encaps: 35, #pkts encrypt: 35, #pkts digest: 35
      #pkts decaps: 17, #pkts decrypt: 17, #pkts verify: 17
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 35, #pkts comp failed: 0, #pkts decomp failed: 0

OUTPUT WHILE TRYING ICMP TRAFFIC:

      #pkts encaps: 45, #pkts encrypt: 45, #pkts digest: 45
      #pkts decaps: 17, #pkts decrypt: 17, #pkts verify: 17
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 45, #pkts comp failed: 0, #pkts decomp failed: 0

OUTPUT WHILE TRYING NON-ICMP TRAFFIC AFTER FEW PINGS:

    #pkts encaps: 59, #pkts encrypt: 59, #pkts digest: 59
      #pkts decaps: 31, #pkts decrypt: 31, #pkts verify: 31
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 59, #pkts comp failed: 0, #pkts decomp failed: 0

Shqiptari · ‎10-04-2010

-- Oops wrong forum

brettborschel · ‎10-05-2010

The problem here is that the tunnel does work. Just not always. This will have nothing to do with either HTTP or ICMP. They both fall under the permit IP ACL. You either have a mismatch ACL on one side or the other. They must be identical oposites. It is very plausible that a subnet mask is bad or something equally as stupid like the FW needs a reload.

The sugestions for turning on persistant pings or isakmp keepalives are taking you down the wrong path. This will not fix your problem.

First off, VPN on the PIX sucks. Its buggy. I have pulled out many hairs troubleshooting problems where the config was right but the tunnel was not. With PIX for some reason a VPN tunnel is never quite done until a reload happens. Try that to fix your problem.

If I were you, I would stick a router behind the PIX and use the FW to just permit ISAKMP and ESP to the router. I can build a tunnel router to router in about 5 minutes. PIX will inevitably take me hours.

Second, if you really need persistant tunnels that stay up all the time, you can't use PIX for VTI or GRE IPSEC tunnels. Another nice thing with VTI tunnels is that you dont need any crypto ACLs. You can run an routing protocol on both sites and if the routing table figures out that packets need to come accross the tunnel, they do with no questions asked.

Third, your crypto ACL is getting long. This always complicates things as both sides will have to look at all rules to find a match before agreeing that the interesting traffic is permitted. A general rule of thumb, make your VPN ACL open and your FW rules tight.