1

I'm configuring a VPN connection between two sites. Site A has an ASA (9.8.2) and the other site an ISR 2911 (15.4 I think - I'll have to double check). I'm using VTIs for a routed VPN. The tunnel is Up/Up on both sides.

From the perspective of Site B, I'm seeing decaps and decrypts when I try to ping from one tunnel interface to the other. However, there are no encaps/encrypts going the other way. Not even when I try to ping from site B to Site A.

Basic connection diagram

The configuration of Site B is as follows:

crypto ipsec security-association replay window-size 128
crypto ipsec fragmentation before-encryption
crypto ipsec df-bit clear

! Note: Use IKEv2 Smart Defaults for proposal

! Note: Use IKEv2 Smart Defaults for policy

crypto ikev2 keyring myV1-keyring
 peer remote-peer
  address 190.191.192.193
  identity address 190.191.192.193
  pre-shared-key local sideb-psk
  pre-shared-key remote sidea-psk

crypto ikev2 profile sideb-ikev2
 match identity remote address 190.191.192.193 255.255.255.255
 ivrf employeeVrf
 authentication local pre-share 
 authentication remote pre-share
 dpd 1000 60 periodic
 identity local address 100.101.102.103
 keyring local myV1-keyring
 ! Note: Use default lifetime settings

crypto ipsec transform-set my-tansform esp-aes 256 esp-sha512-hmac
  mode tunnel

crypto ipsec profile sideb-ipsec
 set pfs group5
 set transform-set my-tansform
 set ikev2-profile sideb-ikev2

interface tunnel 0
 ip vrf forwarding employeeVrf
 ip address 10.10.10.3 255.255.255.248
 tunnel mode ipsec ipv4
 tunnel source GigabitEthernet0/0
 tunnel destination 190.191.192.193
 tunnel protection ipsec profile sideb-ipsec

I have not included Site A because it seems irrelevant at this point. The tunnel is up/up at Site A, and it's encapsulating packets to be decapsulated on the remote end (Site B). The encapsulation of packets at Site B should occur regardless of Site A's ability to decapsulate them, but it's not. Therefore, my conclusion is that I can ignore Site A, at least until I see encapsulation occurring at Site B.

Note: The ivrf is employeeVrf, while the fvrf is default/global.

With the tunnel's reporting as up/up...

From site A, ping 10.10.10.3 results in no replies (100% loss) From Site B, ping vrf employeeVrf 10.10.10.1 results in no replies (100% loss)

However,

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 100.101.102.103

   protected vrf: employeeVrf
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   current_peer 190.191.192.193 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #pkts no sa (send) 0, #pkts invalid sa (rcv) 0
    #pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
    #pkts invalid prot (recv) 0, #pkts verify failed: 0
    #pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
    #pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
    ##pkts replay failed (rcv): 0
    #pkts tagged (send): 0, #pkts untagged (rcv): 0
    #pkts not tagged (send): 0, #pkts not untagged (rcv): 0
    #pkts internal err (send): 0, #pkts internal err (recv) 0

     local crypto endpt.: 100.101.102.103, remote crypto endpt.: 190.191.192.193
     plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
     current outbound spi: 0xD7D32882(3620939906)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x19478282(424116866)
        transform: esp-256-aes esp-sha512-hmac ,
        in use settings ={Tunnel, }
        conn id: 3893, flow_id: Onboard VPN:1893, sibling_flags 80000040, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4292784/3200)
        IV size: 16 bytes
        replay detection support: Y  replay window size: 128
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xD7D32882(3620939906)
        transform: esp-256-aes esp-sha512-hmac ,
        in use settings ={Tunnel, }
        conn id: 3894, flow_id: Onboard VPN:1894, sibling_flags 80000040, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4292784/3200)
        IV size: 16 bytes
        replay detection support: Y  replay window size: 128
        Status: ACTIVE(ACTIVE)

     outbound ah sas:

     outbound pcp sas:

Note that we see the 5 decaps and decrypts from the Site A to Site B ping. There are no encrypts for replies, or from the Site B to Site A ping.

It's also interesting to note "PFS (Y/N): N, DH group: none". I don't understand this because I've specified PFS in my ipsec profile as group 5. The SA on the remote side (Site A) does report PFS as expected.

Any help or insight regarding a mis-configuration or solution is greatly appreciated.

4

First thing you need to do is remove the ivrf from the ikev2 profile, as it's not needed (and probably causing the issue).

crypto ikev2 profile sideb-ikev2
no ivrf employeeVrf

Then ...

Run a show ip route 10.10.10.1 and show ip cef tunnel0 to see if the tunnel network is showing as a connected route.

I've never used the global table AND an inside VRF, I've always specified both ...

I would try defining an fvrf (let's call my example outsideVRF). This would then need to be set in your keyring, as a tunnel vrf, as well as the match statements.

crypto ikev2 keyring myV1-keyring vrf outsideVRF

interface tunnel0
tunnel vrf outsideVRF

match identity remote address 190.191.192.193 255.255.255.255 vrf outsideVRF

Then you can worry about routing across the tunnel (remembering to include the proper VRF in your route statements).

Let us know how it goes.

  • Nailed it! After removing the 'ivrf' statement from my ikev2 profile, everything started working! Well, at least I can ping the other side of the tunnel... – Matthew Johnson Apr 17 '18 at 13:32
  • Great to hear man! If you can ping the other side, routing should be a breeze (you now have a next hop address). Lemme know if you need any assistance with that. Glad to hear you got it working :) – fencepencil Apr 17 '18 at 18:58
1

I have not included Site A because it seems irrelevant at this point

But it isn't. Each direction is an independant flow, with its own SA. If you have one-way traffic (as you do), the return direction didn't setup correctly (or at all), and/or traffic isn't being routed into it. We need to see what's what on both sides. I suspect it's the latter as there's two SAs. debug packet may shed some light on where things are going/being dropped.

(Note: Historically ASAs have not supported VTI -- because an ASA cannot do "0/0" and IOS, relying on routing, can't be set any more specific.)

  • Each direction is an independent flow with it's own SA as you say - the inbound SA SPI is 0x19478282. The outbound SA SPI is 0xD7D32882, which wouldn't exist without a corresponding SA on the other side. There are no encapsulated packets leaving, so the other side doesn't even have a chance to cause problems unrelated to the initial negotiation. – Matthew Johnson Apr 16 '18 at 21:00
  • VTI support was added to ASAs in 9.7 – Matthew Johnson Apr 16 '18 at 21:01
  • I know -- I'm also assuming it's not 100% bug-free. Again, use some debug's to find out what IOS is doing with the packets. It's either not sending them to the VTI, or failing to encrypt them. – Ricky Beam Apr 16 '18 at 21:12
  • Good point, I shouldn't dismiss the possibility altogether. As far as I can tell, debug logs indicated the ASA side was working as expected. Then again, VPN related logs are difficult for me to read. Thanks for your input. – Matthew Johnson Apr 17 '18 at 13:30

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.