Announcement

Collapse
No announcement yet.

VPN issue: one subnet not being sent over tunnel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • VPN issue: one subnet not being sent over tunnel

    VPN issue: one subnet not being sent over VPN tunnel, another one is.


    I'm trying to troubleshoot a VPN problem. This end is a Cisco ASA 5510, the other end is a Checkpoint software firewall.

    There are two local subnets (I'll call them 10.55.55.0/24 and 10.66.66.0/24) and one remote subnet I care about for now (172.16.1.0/24)
    My local endpoint is 1.1.1.1, the remote endpoint is 2.2.2.2

    There are multiple VPNs connected to this ASA, all except this one work fine.

    The VPN tunnel comes up fine, and in the logs (at debug level) I can see it hunt through the different VPNs defined until it finds the right one:

    Code:
    Static Crypto Map check, checking map = outside_map, seq = 20...
    Static Crypto Map check, map = outside_map, seq = 20, ACL does not match proxy IDs src:172.16.1.0 dst:10.66.66.0
    [...]
    Static Crypto Map check, checking map = outside_map, seq = 120...
    Static Crypto Map check, map = outside_map, seq = 120, ACL does not match proxy IDs src:172.16.1.0 dst:10.66.66.0
    Static Crypto Map check, checking map = outside_map, seq = 140...
    Static Crypto Map check, map outside_map, seq = 140 is a successful match
    IKE Remote Peer configured for crypto map: outside_map
    processing IPSec SA payload
    The problem is the tunnel doesn't seem to be encapsulating outbound traffic properly - inbound traffic is fine, and if a remote user pings something on the 10.55.55.0 subnet they get a response but traffic from 10.66.66.0 vanishes.

    I can see this in 'show crypto ipsec sa' - note that it show 0 encapsulations from the 10.66.66.0 subnet

    Code:
      Crypto map tag: outside_map, seq num: 140, local addr: 1.1.1.1
    
          access-list outside_cryptomap_140 permit ip 10.55.55.0 255.255.255.0 172.16.1.0 255.255.255.0
          local ident (addr/mask/prot/port): (10.55.55.0/255.255.255.0/0/0)
          remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)
          current_peer: 2.2.2.2
    
          #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
          #pkts decaps: 6, #pkts decrypt: 6, #pkts verify: 6
          #pkts compressed: 0, #pkts decompressed: 0
          #pkts not compressed: 9, #pkts comp failed: 0, #pkts decomp failed: 0
          #send errors: 0, #recv errors: 0
    
          local crypto endpt.: 1.1.1.1, remote crypto endpt.: 2.2.2.2
    
          path mtu 1500, ipsec overhead 76, media mtu 1500
          current outbound spi: D0D69617
    
        inbound esp sas:
          spi: 0xDDA729EE (3718719982)
             transform: esp-aes-256 esp-sha-hmac
             in use settings ={L2L, Tunnel, }
             slot: 0, conn_id: 189, crypto-map: outside_map
             sa timing: remaining key lifetime (sec): 2057
             IV size: 16 bytes
             replay detection support: Y
        outbound esp sas:
          spi: 0xD0D69617 (3503724055)
             transform: esp-aes-256 esp-sha-hmac
             in use settings ={L2L, Tunnel, }
             slot: 0, conn_id: 189, crypto-map: outside_map
             sa timing: remaining key lifetime (sec): 2057
             IV size: 16 bytes
             replay detection support: Y
    
    
       Crypto map tag: outside_map, seq num: 140, local addr: 1.1.1.1
    
          access-list outside_cryptomap_140 permit ip 10.66.66.0 255.255.255.0 172.16.1.0 255.255.255.0
          local ident (addr/mask/prot/port): (10.66.66.0/255.255.255.0/0/0)
          remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)
          current_peer: 2.2.2.2
    
          #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
          #pkts decaps: 189, #pkts decrypt: 189, #pkts verify: 189
          #pkts compressed: 0, #pkts decompressed: 0
          #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
          #send errors: 0, #recv errors: 0
    
          local crypto endpt.: 1.1.1.1, remote crypto endpt.: 2.2.2.2
    
          path mtu 1500, ipsec overhead 76, media mtu 1500
          current outbound spi: 72AD1646
    
        inbound esp sas:
          spi: 0x2F1AA0DE (790274270)
             transform: esp-aes-256 esp-sha-hmac
             in use settings ={L2L, Tunnel, }
             slot: 0, conn_id: 189, crypto-map: outside_map
             sa timing: remaining key lifetime (sec): 1232
             IV size: 16 bytes
             replay detection support: Y
        outbound esp sas:
          spi: 0x72AD1646 (1923946054)
             transform: esp-aes-256 esp-sha-hmac
             in use settings ={L2L, Tunnel, }
             slot: 0, conn_id: 189, crypto-map: outside_map
             sa timing: remaining key lifetime (sec): 1232
             IV size: 16 bytes
             replay detection support: Y

    "#pkts encaps: 0" makes me worry that the ASA is not encapsulating the outbound traffic from 10.66.66.0, even though I can't figure out why this would be.

    NAT rules are setup in a way that should avoid any NAT for traffic intended for the VPN:

    Code:
    global (outside) 1 1.1.1.1
    nat (secondarynetwork) 0 0.0.0.0 0.0.0.0
    nat (SERVERS) 0 access-list SERVERS_nat0_outbound    
    nat (SERVERS) 1 10.66.66.0 255.255.255.0      
    static (SERVERS,outside) 1.1.1.1 10.55.55.8 netmask 255.255.255.255 
    static (secondarynetwork,SERVERS) 10.254.0.0 10.254.0.0 netmask 255.255.0.0 
    static (secondarynetwork,SERVERS) 172.19.200.0 172.19.200.0 netmask 255.255.255.0
    (10.55.55.8 is the IP of a web server that is accessed both over the internet (https://1.1.1.1) and over the VPN tunnel (http://10.55.55.8). SERVERS in teh interface for the inside Servers. secondarynetwork is another network, not part of the VPN setup. )

    The following lines are in SERVERS_nat0_outbound:

    Code:
    access-list PORTAL_nat0_outbound extended permit ip 10.66.66.0 255.255.255.0 172.16.1.0 255.255.255.0 
    access-list PORTAL_nat0_outbound extended permit ip 10.55.55.0 255.255.255.0 172.16.1.0 255.255.255.0
    I've gone through http://www.cisco.com/en/US/products/...807e0aca.shtml but can't fidn anything else to look at to help figure out why one subnet is happy and the other isn't.. could this be caused by something in the remote VPN config that has made the local ASA decide not to encapsulate the traffic from 10.66.66.0 to 172.16.1.0, or is there a setting I've missed?

  • #2
    Re: VPN issue: one subnet not being sent over tunnel

    May be a typo but at the bottom of your post you state these are the servers in "SERVERS_nat0_outbound" yet the code shows "PORTAL_nat0_outbound"
    cheers
    Andy

    Please read this before you post:


    Quis custodiet ipsos custodes?

    Comment

    Working...
    X