4

I have a VTI tunnel configured between two devices (ASR and ASAv). The tunnel comes up fine and is stable, however traffic appears to be unidirectional, from the ASR -> ASAv but not in the reverse direction.

I can see nothing wrong in the config. There are suitable routes at both ends, although each end of the tunnel can't even ping the other end, and they are connected routes on both sides.

ASR (CSR) config:

ip vrf CUSTOMER
 rd 1:1
!
crypto keyring KEY-CUSTOMER
  local-address 1.2.43.247
  pre-shared-key address 1.2.41.130 key ****************
!
crypto isakmp policy 200
 encr aes
 authentication pre-share
 group 2
 lifetime 28800
crypto isakmp keepalive 10 10 periodic
crypto isakmp profile PROF-CUSTOMER
   keyring KEY-CUSTOMER
   match identity address 1.2.41.130 255.255.255.255
   local-address 1.2.43.247
!
crypto ipsec security-association replay window-size 128
!
crypto ipsec transform-set CUSTOMER-TRANSFORM esp-aes esp-sha-hmac
 mode tunnel
crypto ipsec df-bit clear
!
crypto ipsec profile PROF-IPSEC-CUSTOMER
 set transform-set CUSTOMER-TRANSFORM
 set pfs group2
!
interface Loopback5
 description VRF CUSTOMER LOOPBACK
 ip vrf forwarding CUSTOMER
 ip address 10.255.255.255 255.255.255.255
!
interface Tunnel5
 description CUSTOMER IPSEC TUNNEL
 ip vrf forwarding CUSTOMER
 ip address 10.200.0.1 255.255.255.252
 tunnel source 1.2.43.247
 tunnel destination 1.2.41.130
 tunnel protection ipsec profile PROF-IPSEC-CUSTOMER
!
interface GigabitEthernet1
 ip address 1.2.43.247 255.255.0.0
 negotiation auto

ASAv config:

interface GigabitEthernet0/0
 nameif OUTSIDE
 security-level 0
 ip address 1.2.41.130 255.255.0.0
!
interface Tunnel1
 nameif LTE
 ip address 10.200.0.2 255.255.255.252
 tunnel source interface OUTSIDE
 tunnel destination 1.2.43.247
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile PROF-PROVIDER-LTE
!
crypto ipsec ikev1 transform-set TS-PROVIDER-LTE esp-aes esp-sha-hmac
crypto ipsec profile PROF-PROVIDER-LTE
 set ikev1 transform-set TS-PROVIDER-LTE
 set pfs group2
 set security-association lifetime seconds 3600
crypto ipsec security-association pmtu-aging infinite
!
crypto ikev1 enable OUTSIDE
crypto ikev1 policy 30
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 28800
tunnel-group 1.2.43.247 type ipsec-l2l
tunnel-group 1.2.43.247 ipsec-attributes
 ikev1 pre-shared-key *****

Packets enter the tunnel from the ASR (CSR):

CSR#ping vrf CUSTOMER 10.200.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CSR#sh int t5
Tunnel5 is up, line protocol is up
  Hardware is Tunnel
  Description: CUSTOMER IPSEC TUNNEL
  Internet address is 10.200.0.1/30
  MTU 9914 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 1.2.43.247, destination 1.2.41.130
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1414 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "PROF-IPSEC-CUSTOMER")
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 00:25:24
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     12 packets output, 1488 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

And exit the tunnel on the ASAv:

ASAv(config)# sh crypto ipsec sa
interface: LTE
    Crypto map tag: __vti-crypto-map-3-0-1, seq num: 65280, local addr: 1.2.41.130

      local ident (addr/mask/prot/port): (1.2.41.130/255.255.255.255/47/0)
      remote ident (addr/mask/prot/port): (1.2.43.247/255.255.255.255/47/0)
      current_peer: 1.2.43.247


      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 12, #pkts decrypt: 12, #pkts verify: 12
      #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.: 1.2.41.130/0, remote crypto endpt.: 1.2.43.247/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: E0E7EF24
      current inbound spi : 728E0529

    inbound esp sas:
      spi: 0x728E0529 (1921910057)
         SA State: active
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, VTI, }
         slot: 0, conn_id: 1, crypto-map: __vti-crypto-map-3-0-1
         sa timing: remaining key lifetime (kB/sec): (3914998/2177)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00001FFF
    outbound esp sas:
      spi: 0xE0E7EF24 (3773296420)
         SA State: active
         transform: esp-aes esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, VTI, }
         slot: 0, conn_id: 1, crypto-map: __vti-crypto-map-3-0-1
         sa timing: remaining key lifetime (kB/sec): (3915000/2177)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

But nothing flows in the return direction.

Both devices have sensible routes:

CSR# sh ip route vrf CUSTOMER

Routing Table: CUSTOMER
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.200.0.0/30 is directly connected, Tunnel5
L        10.200.0.1/32 is directly connected, Tunnel5
C        10.255.255.255/32 is directly connected, Loopback5



ASAv(config)# sh route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is not set

C        10.200.0.0 255.255.255.252 is directly connected, LTE
L        10.200.0.2 255.255.255.255 is directly connected, LTE
C        1.2.0.0 255.255.0.0 is directly connected, OUTSIDE
L        1.2.41.130 255.255.255.255 is directly connected, OUTSIDE

I have tried adding a static route on the ASAv to point back down the tunnel but this fails as there is already a connected route, albeit one which seems not to work.

Improve this question
2
  • Are there policies or security levels on the ASA that might be dropping traffic into the tunnel?
    – Ron Trunk
    Commented Jun 25, 2021 at 13:37
  • The test above is on a clean image, so all of the relevant config is in the snippets. I tried with and without security levels. The behaviour is exactly the same as the live kit I tried this on initially, packets in one direction but nothing back out of the ASA.
    – btongeorge
    Commented Jun 25, 2021 at 14:26

1 Answer 1

Reset to default
4

I found the solution to this eventually, with some help.

The issue was that on the ASR side, the tunnel was in its default configuration which uses GRE, which the ASA doesn't support.

The solution was to change the tunnel mode to ipsec ipv4 like so:

interface Tunnel5
 tunnel mode ipsec ipv4

With this done, bidirectional traffic was possible over the tunnel.

Improve this answer
1
  • For the record, you never mentioned you had an ASR in the picture. You only mentioned it as “CSR”. I’ve edited your original question to clarify that.
    – Jesse P.
    Commented Sep 10, 2021 at 23:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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