3

Ok, so I have a simple VPN IPSEC setup with a single Linux host that has a public IP address and a loopback interface of 172.16.255.1. On the right side I have a Cisco ASA 5505 9.1. the issue is the Cisco ASA says when debugging "PHASE 2 Completed" so i know there is no conflict with my ISKMP negotiation. However I am receiving the following which should indicates a Network ACL mismatch, but I cannot figure it out.

Apr 09 14:30:26 [IKEv1 DEBUG]Group = x.x.137.133, IP = x.x.137.133, IKE got a KEY_ADD msg for SA: SPI = 0x61af9f82
Apr 09 14:30:26 [IKEv1 DEBUG]Group = x.x.137.133, IP = x.x.137.133, Pitcher: received KEY_UPDATE, spi 0x95cad3f0
Apr 09 14:30:26 [IKEv1 DEBUG]Group = x.x.137.133, IP = x.x.137.133, Starting P2 rekey timer: 27360 seconds.
Apr 09 14:30:26 [IKEv1]Group = x.x.137.133, IP = x.x.137.133, PHASE 2 COMPLETED (msgid=0504e77c)
Apr 09 14:23:29 [IKEv1]Group = x.x.137.133, IP = x.x.137.133, Received non-routine Notify message: Invalid ID info (18)

And on the Linux box running OpenSwan I see:

"L2L-IPSEC-CT" #1: the peer proposed: 172.16.255.1/32:0/0 -> 192.168.0.0/24:0/0
"L2L-IPSEC-CT" #1: cannot respond to IPsec SA request because no connection is known for 172.16.255.1/32===x.x.137.133<x.x.137.133>[+S=C]:1/0...x.x.157.15<x.x.157.15>[+S=C]:1/0===192.168.0.0/24
"L2L-IPSEC-CT" #1: sending encrypted notification INVALID_ID_INFORMATION to x.x.157.15:500

After doing some reseach it seems to be an issue with the proposed Networks allowed to traverse the tunnel. however my configs on both are the sames

Cisco config

access-list VPN-TRAFFIC-VPS1 line 1 extended permit icmp 192.168.0.0 255.255.255.0 host 172.16.255.1 (hitcnt=422) 0x150f2cfc
access-list VPN-TRAFFIC-VPS1 line 2 extended permit ip 192.168.0.0 255.255.255.0 host 172.16.255.1 (hitcnt=42) 0xfd98dbac

Openswan Config

conn L2L-IPSEC-CT
        auto=start #automatically start if detected
        type=tunnel #tunnel mode/not transport
        compress=no

        ###THIS SIDE###
        left=x.x.137.133
        leftsubnet=172.16.255.1/32

        ###PEER SIDE###
        right=x.x.157.15
        rightsubnet=192.168.0.0/24

        #phase 1 encryption-integrity-diffhellman
        keyexchange=ike
        ike=3des-md5-modp1024,aes256-sha1-modp1024
        ikelifetime=86400s
        authby=secret #use presharedkey

        #phase 2 encryption-pfsgroup
        phase2=esp #esp for encryption | ah for authentication only
        phase2alg=3des-md5;modp1024
        pfs=no

My test has been a ping from 192.168.0.200 toward 172.16.255.1: Here is the show crypto ipsec sa

asa(config)# show crypto ipsec sa
interface: outside
    Crypto map tag: outside-cmap, seq num: 40, local addr: x.x.157.15

      access-list VPN-TRAFFIC-VPS1 extended permit ip 192.168.0.0 255.255.255.0 host 172.16.255.1
      local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (172.16.255.1/255.255.255.255/0/0)
      current_peer: x.x.137.133

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #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
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: x.x.157.15/0, remote crypto endpt.: x.x.137.133/0
      path mtu 1500, ipsec overhead 58(36), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: 61AF9F82
      current inbound spi : 95CAD3F0

Open swan ipsec auto --status

**000 "L2L-IPSEC-CT": 172.16.255.1/32===x.x.137.133<x.x.137.133>[+S=C]...x.x.157.15<x.x.157.15>[+S=C]===192.168.0.0/24; erouted; eroute owner: #4
000 "L2L-IPSEC-CT":     myip=unset; hisip=unset;
000 "L2L-IPSEC-CT":   ike_life: 86400s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "L2L-IPSEC-CT":   policy: PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,24; interface: eth0;
000 "L2L-IPSEC-CT":   newest ISAKMP SA: #3; newest IPsec SA: #4;
000 "L2L-IPSEC-CT":   IKE algorithms wanted: 3DES_CBC(5)_000-MD5(1)_000-MODP1024(2), AES_CBC(7)_256-SHA1(2)_000-MODP1024(2); flags=-strict
000 "L2L-IPSEC-CT":   IKE algorithms found:  3DES_CBC(5)_192-MD5(1)_128-MODP1024(2), AES_CBC(7)_256-SHA1(2)_160-MODP1024(2)
000 "L2L-IPSEC-CT":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1024
000 "L2L-IPSEC-CT":   ESP algorithms wanted: 3DES(3)_000-MD5(1)_000; pfsgroup=MODP1024(2); flags=-strict
000 "L2L-IPSEC-CT":   ESP algorithms loaded: 3DES(3)_192-MD5(1)_128
000 "L2L-IPSEC-CT":   ESP algorithm newest: 3DES_000-HMAC_MD5; pfsgroup=<N/A>
000
000 #4: "L2L-IPSEC-CT":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27518s; newest IPSEC; eroute owner; isakmp#3; idle; import:admin initiate
000 #4: "L2L-IPSEC-CT" esp.95cad3f0@x.x.157.15 esp.61af9f82@x.x.137.133 tun.0@x.x.157.15 tun.0@x.x.137.133 ref=0 refhim=4294901761
000 #3: "L2L-IPSEC-CT":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 85221s; newest ISAKMP; lastdpd=1s(seq in:0 out:0); idle; import:admin initiate
**

I'm really lost as to why this isn't working. Perhaps a new set of eyes, since I've been working on this for 3 days! Yikes!

Appreciate your help serverfault community!

P.S. Is there any OpenSwan commands i can use to verify the subnets in question are being picked up by the tunnel "openswan"

  • is pfs disabled on the asa? what 9.1 version is on the asa? there are a lot of vpn bugs in 9.1(1) – user1008764 Apr 9 '14 at 21:26
  • pfs is disabled on Openswan and Cisco ASA. Cisco ASA version 9.1(3). I have pings working when originating ont eh Cisco ASA side, but I can't ping anything from the Openswan side. So weird. – Jim Apr 10 '14 at 13:04
  • adding leftsidesourceip helped with issues of One Direction Pings. – Jim Apr 10 '14 at 13:08
2

Ok, so I beliveve I figured it out.

So even though my Openswan box is not behind a NAT, and has a direct NIC with a public IP I had to turn on NAT-Traversal. With this in mind I had to add leftsoureip=172.16.255.1 to tell Openswan what source address to use when communicating with the right side of the Tunnel. The last thing I had to do was to enable forceencaps. For some reason as soon as I did this the tunnel started working.

config setup
     listen=x.x.137.133
     nat_traversal=yes
     virtual_private=%v:172.16.255.1/32,192.168.0.0/24
     oe=off
     protostack=netkey

conn L2L-IPSEC-CT
    auto=start #automatically start if detected
    type=tunnel #tunnel mode/not transport
    compress=no

    ###THIS SIDE###
    left=x.x.137.133
    leftid=x.x.137.133
    leftsubnet=172.16.255.1/32
    leftsourceip=172.16.255.1

    ###PEER SIDE###
    right=x.x.157.15
    rightid=x.x.157.15
    rightsubnet=192.168.0.0/24

    #phase 1 encryption-integrity-diffhellman
    keyexchange=ike
    ike=3des-md5-modp1024,aes256-sha1-modp1024
    ikelifetime=86400s
    authby=secret #use presharedkey

    #phase 2 encryption-pfsgroup
    phase2=esp #esp for encryption | ah for authentication only
    phase2alg=3des-md5;modp1024
    pfs=no
    forceencaps=yes

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.