5550 ACL drop/IP spoof/VPN issue

[bellinom1]

Hey all,

I am trying to enable VPN access from the testing interface to the wifi interface. I get an implicit ACL drop in packet-tracer, and Deny IP spoof log messages, even though RPF is not enabled on either interface. VPN is currently working for hosts on the wifi interface, so I don't belive it's a VPN issue. Any help would be greatly appreciated.

Here's the relevant config:

! Log message about IP spoof
Feb 22 2016 11:10:01: %ASA-2-106016: Deny IP spoof from (10.1.225.51) to 172.20.16.2 on interface testing

! Wifi interface where VPN is enabled
interface GigabitEthernet1/0.121
description Wifi interface
vlan 121
nameif Wifi
security-level 0
ip address 172.20.16.2 255.255.240.0

! testing interface that needs access to VPN
interface GigabitEthernet1/1.225
vlan 225
nameif testing
security-level 50
ip address 10.1.225.1 255.255.255.0

same-security-traffic permit intra-interface
same-security-traffic permit inter-interface

! Gateway object for NAT and ACL entries
object network nWIFI_GATEWAY
subnet 172.20.16.0 255.255.240.0
description Wifi network default gateway

! Testing network for NAT and ACL entries
object network nTESTING
subnet 10.1.225.0 255.255.255.0
description Testing subnet

! NAT statements, may be redundant
nat (Wifi,testing) source static nWIFI_GATEWAY nWIFI_GATEWAY
nat (testing,Wifi) source static nTESTING nTESTING

! Wifi interface ACL
access-list acl_wifi_int extended permit ip any object nTESTING
access-list acl_wifi_int extended permit icmp any object nTESTING
access-list acl_wifi_int extended permit icmp object nTESTING any
access-list acl_wifi_int extended permit ip object nWIFI_GATEWAY object nTESTING
access-list acl_wifi_int extended permit ip object nTESTING object nWIFI_GATEWAY

! testing interface ACL
access-list testing_access_in extended permit ip any object nWIFI_GATEWAY
access-list testing_access_in extended permit icmp any any
access-list testing_access_in extended permit ip object nWIFI_GATEWAY any
access-list testing_access_in extended permit ip any any

! Packet-tracer output

packet-tracer input testing tcp 10.1.225.51 80 172.20.16.2 80 d

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x3e3c1da8, priority=13, domain=capture, deny=false
hits=11839, user_data=0x40616e38, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=testing, output_ifc=any

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x34f85da0, priority=1, domain=permit, deny=false
hits=23163, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=testing, output_ifc=any

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (Wifi,testing) source static nWIFI_GATEWAY nWIFI_GATEWAY
Additional Information:
NAT divert to egress interface Wifi
Untranslate 172.20.16.2/80 to 172.20.16.2/80

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group testing_access_in in interface testing
access-list testing_access_in extended permit ip any object nWIFI_GATEWAY
Additional Information:
Forward Flow based lookup yields rule:
in id=0x4234a410, priority=13, domain=permit, deny=false
hits=558, user_data=0x1dae8780, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=172.20.16.0, mask=255.255.240.0, port=0, dscp=0x0
input_ifc=testing, output_ifc=any

Phase: 5
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x22b9d7c8, priority=7, domain=conn-set, deny=false
hits=869, user_data=0x225f3c38, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=testing, output_ifc=any

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x43024750, priority=0, domain=inspect-ip-options, deny=true
hits=2214, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=testing, output_ifc=any

Phase: 7
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2fe6df28, priority=21, domain=lu, deny=true
hits=494, user_data=0x0, cs_id=0x0, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=80, dscp=0x0
input_ifc=testing, output_ifc=any

Phase: 8
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (testing,Wifi) source static nTESTING nTESTING
Additional Information:
Forward Flow based lookup yields rule:
in id=0x4234a9c8, priority=6, domain=nat, deny=false
hits=688, user_data=0x2660cd00, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=10.1.225.0, mask=255.255.255.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=testing, output_ifc=Wifi

Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (Wifi,testing) source static nWIFI_GATEWAY nWIFI_GATEWAY
Additional Information:
Forward Flow based lookup yields rule:
out id=0x2b45c9d8, priority=6, domain=nat-reverse, deny=false
hits=559, user_data=0x3e9e8ad8, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=172.20.16.0, mask=255.255.240.0, port=0, dscp=0x0
input_ifc=testing, output_ifc=Wifi

Phase: 10
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x2550f6b8, priority=0, domain=user-statistics, deny=false
hits=220372121, user_data=0x2608f798, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=any, output_ifc=Wifi

Phase: 11
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Reverse Flow based lookup yields rule:
in id=0x22e143f8, priority=500, domain=permit, deny=true
hits=7969, user_data=0x6, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=172.20.16.2, mask=255.255.255.255, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=Wifi, output_ifc=any

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

[bellinom1]

Forgot to mention I'm running 8.4(4)1.

[bellinom1]

Does anyone have any advice on this?

[patoberli]

My gut feeling tells me it's a NAT issue, but I'm not sure. Could you first try to not NAT anything?

Also, you might, just for a try, change the access-list acl_wifi_int to add a permit ip any any at the end, just for quick testing.

Oh, you also might want to update to ASA 9.x code, they changed several VPN behavior things and a few PAT details, not NAT though, as far as I remember.

[bellinom1]

Thanks for your help patoberli.

I've removed the NAT statements:

no nat (testing,Wifi) source static nTESTING nTESTING
no nat (Wifi,testing) source static nWIFI_GATEWAY nWIFI_GATEWAY

Unfortunately we are stuck on 8.4 code for the near future.

Packet-tracer now gives me this:

packet-tracer input testing tcp 10.1.225.51 80 172.20.16.2 80 d

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x34f85da0, priority=1, domain=permit, deny=false
hits=42709, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=testing, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.20.16.2 255.255.255.255 identity

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x34f86c78, priority=0, domain=permit, deny=true
hits=69, user_data=0x9, cs_id=0x0, use_real_addr, flags=0x1000, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=testing, output_ifc=any

Result:
input-interface: testing
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[patoberli]

Can you show me your lines starting with "access-group" ?

Oh and I checked my configuration, I also have NAT for our VPN users configured. My rule does look way different though:

nat (VPN_IN,any) source static range-172.16.0.0_16 range-172.16.0.0_16 destination static range-192.168.0.0_16 range-192.168.0.0_16

172.16.0.0/16 is VPN and 192.168.0.0/16 includes all internal networks spread over other interfaces.

It's some years since I did this configuration and I'm not anymore fully sure what more is needed.

[Marius Gunnerud · Accepted solution]

Your packet tracer is to the ASA Wifi interface and this it is being dropped.  You will never be able to connect to an ASA interface that is not the ingress interface. try packet tracer to 172.20.16.3 instead

--

Please remember to select a correct answer and rate helpful posts

[bellinom1]

Wow, you nailed it. That didn't even occur to me. Packet-tracer to 172.20.16.3 works just fine. My issue now is that the VPN address is on the wifi interface, using the interface address.

[Marius Gunnerud]

So what is the problem with the VPN? Do you have a VPN terminated on the testing interface? is it a site 2 site vpn or a remote access vpn?

Please explain in more detail what the issue you're facing.

--

Please remember to select a correct answer and rate helpful posts

[bellinom1]

This what I'm trying to accomplish. Wireless users on the wifi interface use VPN to access internal domain resources, using vpn.ourcompany.com, which resolves to the wifi interface address, 172.20.16.2.

My thought was to use that same interface as the VPN interface for users on the testing interface. I have web and client-based VPN enabled on both wifi and testing.

The whole point of all this is an OpenDNS trial we are running. We have external DNS servers for wireless users, and testing will use those as well, and internal ones for users on the inside interface. I hope that explains what I'm trying to accomplish.

[bellinom1]

VPN is working on the testing interface now. I just need to mess with DNS now to get it to resolve correctly for hosts inside it. I believe my problem is resolved. Thanks for all the help.

[Marius Gunnerud]

Since wireless users are directly connected to the Wifi interface why bother with a VPN?

So OpenDNS is resolving URLs to internal IPs? Do you have split-tunnel configured? if yes, have you added the internal IPs you are trying to reach to the split-tunnel ACL.

Testing Open DNS is fine, but still need more info on what your problem with the VPN is.  

--

Please remember to select a correct answer and rate helpful posts