cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2904
Views
10
Helpful
3
Replies

ASAv VTI implicit drops

pan.systems
Level 1
Level 1

I'm running ASAv 9.8.1 on QEMU. I'm running a VTI tunnel between the INSIDE interfaces of two ASAvs. I can ping down the tunnel fro ASA to ASA but I cannot get traffic from outside to enter the tunnel. There are NO matches on the OUTSIDE interface ACL, but the same packets are being logged as dropped by an implicit rule.

 

Details below.

 

Any suggestions?

Setup:

  OUTSIDE                           INSIDE                                OUTSIDE
[Laptop]----[ASAv1]----[ROUTER2]-----[ASAv2]-----[ROUTER2]
                             >-------VTI---------<


Problem:
An implicit rule is blocking traffic from OUTSIDE entering the VTI.


Config:

!
interface GigabitEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 10.1.1.1 255.255.255.252
!
interface GigabitEthernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 172.16.1.1 255.255.255.0
!
access-list OUTSIDE-IN extended permit ip 172.16.0.0 255.255.0.0 172.16.0.0 255.255.0.0
access-list OUTSIDE-IN extended permit ip any any
access-list OUTSIDE-IN extended deny ip any any log
!
access-group OUTSIDE-IN in interface OUTSIDE
!

!
crypto ikev1 enable INSIDE
crypto ikev1 am-disable
!
crypto ikev1 policy 1
 authentication pre-share
 encryption des
 hash md5
 group 1
 lifetime 86400
!
tunnel-group 10.3.3.3 type ipsec-l2l
tunnel-group 10.3.3.3 ipsec-attributes
 ikev1 pre-shared-key *****
!
crypto ipsec ikev1 transform-set TEST esp-des esp-sha-hmac
!
crypto ipsec profile VTI
 set ikev1 transform-set TEST
!

!
interface Tunnel1
 nameif VTI1
 ip address 172.16.16.1 255.255.255.252
 tunnel source interface INSIDE
 tunnel destination 10.3.3.3
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
!

Routing is intact:

ciscoasa# sh route 172.16.1.10

Routing entry for 172.16.1.0 255.255.255.0
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Advertised by bgp 1
  Routing Descriptor Blocks:
  * directly connected, via OUTSIDE
      Route metric is 0, traffic share count is 1


ciscoasa# sh route 172.16.3.1

Routing entry for 172.16.3.0 255.255.255.0
  Known via "bgp 1", distance 200, metric 0, type internal
  Last update from 172.16.16.2 0:38:01 ago
  Routing Descriptor Blocks:
  * 172.16.16.2, from 172.16.16.2, 0:38:01 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: no label string provided


ciscoasa# sh route

C        10.1.1.0 255.255.255.252 is directly connected, INSIDE
L        10.1.1.1 255.255.255.255 is directly connected, INSIDE
O        10.2.2.0 255.255.255.252 [110/20] via 10.1.1.2, 02:07:50, INSIDE
O        10.3.3.0 255.255.255.248 [110/20] via 10.1.1.2, 02:07:50, INSIDE
O        10.4.4.0 255.255.255.248 [110/20] via 10.1.1.2, 02:07:50, INSIDE
C        172.16.1.0 255.255.255.0 is directly connected, OUTSIDE
L        172.16.1.1 255.255.255.255 is directly connected, OUTSIDE
B        172.16.3.0 255.255.255.0 [200/0] via 172.16.16.2, 00:36:04
C        172.16.16.0 255.255.255.252 is directly connected, VTI1
L        172.16.16.1 255.255.255.255 is directly connected, VTI1


I can ping down the VTI from ASAv1:

ciscoasa# ping 172.16.16.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.16.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms


I can ping inside interface 10.1.1.2 from OUTSIDE:

ciscoasa# sh access-list OUTSIDE-IN
access-list OUTSIDE-IN; 3 elements; name hash: 0x9ccc1a31
access-list OUTSIDE-IN line 1 extended permit ip 172.16.0.0 255.255.0.0 172.16.0.0 255.255.0.0 (hitcnt=0) 0x8650826a
access-list OUTSIDE-IN line 2 extended permit ip any any (hitcnt=6) 0x03aa8b7f
access-list OUTSIDE-IN line 3 extended deny ip any any log informational interval 300 (hitcnt=0) 0x502c4bfb


But if I ping something down the tunnel from OUTSIDE:

access-list OUTSIDE-IN; 3 elements; name hash: 0x9ccc1a31
access-list OUTSIDE-IN line 1 extended permit ip 172.16.0.0 255.255.0.0 172.16.0.0 255.255.0.0 (hitcnt=0) 0x8650826a
access-list OUTSIDE-IN line 2 extended permit ip any any (hitcnt=6) 0x03aa8b7f
access-list OUTSIDE-IN line 3 extended deny ip any any log informational interval 300 (hitcnt=0) 0x502c4bfb

No matches on the OUTSIDE ACL, but -

ciscoasa# sh log
%ASA-3-106014: Deny inbound icmp src OUTSIDE:172.16.1.10 dst VTI1:172.16.3.1 (type 8, code 0)
%ASA-3-106014: Deny inbound icmp src OUTSIDE:172.16.1.10 dst VTI1:172.16.3.1 (type 8, code 0)
%ASA-3-106014: Deny inbound icmp src OUTSIDE:172.16.1.10 dst VTI1:172.16.3.1 (type 8, code 0)
%ASA-3-106014: Deny inbound icmp src OUTSIDE:172.16.1.10 dst VTI1:172.16.3.1 (type 8, code 0)
%ASA-3-106014: Deny inbound icmp src OUTSIDE:172.16.1.10 dst VTI1:172.16.3.1 (type 8, code 0)
%ASA-3-106014: Deny inbound icmp src OUTSIDE:172.16.1.10 dst VTI1:172.16.3.1 (type 8, code 0)


packet tracer reports:

ciscoasa# packet-tracer input OUTSIDE TCP 172.16.1.10 1024 172.16.3.1 23 det

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.16.16.2 using egress ifc  VTI1

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fe9dd9db380, priority=110, domain=permit, deny=true
        hits=2078, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=OUTSIDE, output_ifc=any

Result:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: VTI1
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

ciscoasa#


As opposed to the INSIDE ping:

ciscoasa# packet-tracer input OUTSIDE TCP 172.16.1.10 1024 10.1.1.2 23 det

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.1.1.2 using egress ifc  INSIDE

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE-IN in interface OUTSIDE
access-list OUTSIDE-IN extended permit ip any any
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fe9ddc70730, priority=13, domain=permit, deny=false
        hits=74, user_data=0x7fe9cf402c80, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=OUTSIDE, output_ifc=any

1 Accepted Solution

Accepted Solutions

Bogdan Nita
VIP Alumni
VIP Alumni

You need to configure same-security-traffic permit inter-interface on both ASAs.

View solution in original post

3 Replies 3

Bogdan Nita
VIP Alumni
VIP Alumni

You need to configure same-security-traffic permit inter-interface on both ASAs.

You sir are a bona-fide genius! That never occurred to me.

 

I've found lots of statements to the effect that there's no security level config for the VTI, but nowhere have I found it stated that the VTI has an implicit security level of 0.

 

Thanks

You are welcome ! I am glad I could help.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: