10-11-2014 04:19 PM
Hello all,
I'm trying to set up an SSL VPN on our ASA 5510 using the Secure Mobility client. After working through several issues, I was able to get the test server to download and install the Linux client, and it says that it's connected. When I try to ping any server inside the LAN though, the first ping is replied to, and the rest time out. On the firewall I see a stream of errors like this:
3 | Oct 11 2014 | 16:12:58 | SRV1 | 172.16.40.185 | Deny inbound icmp src outside:SRV1 dst outside:172.16.40.185 (type 0, code 0) |
split tunneling seems to be working right, I can access the Internet still, but any attempt to reach a server in the LAN times out.
Now I had this working before with a Windows and a Mac client, but deleted that setup and (I thought) completely recreated it when I updated the anyconnect images to include a linux image. Now I get this same problem with all 3 platforms.
Can anyone advise me as to what I may be missing or what I can provide to diagnose the problem?
ASA is running v8.2(5)
I followed this guide to set it up: http://www.techrepublic.com/blog/data-center/eight-easy-steps-to-cisco-asa-remote-access-setup/
Thanks!
Solved! Go to Solution.
10-12-2014 07:10 AM
OK, thanks.
So your clients are being assigned addresses from:
ip local pool VPNTestPool 172.16.40.185-172.16.40.190 mask 255.255.252.0
You've exempted that pool from NAT with the last entry in your nonat acl:
access-list nonat extended permit ip any 172.16.40.184 255.255.255.248
One possible issue I see is that pool is a subnet carved out of your internal network:
ip address 172.16.40.2 255.255.252.0
The ASA will believe hosts in that subnet to be connected and your core may be confused about how to route them.
Also, I don't see where you set the
sysopt connection permit-vpn
...command recommended in the configuration guide you followed.
Also. in your first packet-tracer, the source for the VPN client traffic should be outside, not inside.
10-11-2014 07:05 PM
Can you share the (sanitized) configuration from your ASA?
10-11-2014 09:48 PM
OK it's pretty long and i've cut some chunks out of it.
(See attachment)
I did packet-tracers both ways and here are the results:
ASA# packet-tracer input inside tcp 172.16.40.185 12345 172.16.40.90 80$
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacef5fa0, priority=1, domain=permit, deny=false
hits=30543456, 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
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.16.40.0 255.255.252.0 inside
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xac8106a0, priority=111, domain=permit, deny=true
hits=1932, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
ASA# packet-tracer input inside tcp 172.16.40.90 12345 172.16.40.185 80$
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.16.40.185 255.255.255.255 outside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group 104 in interface inside
access-list 104 extended permit ip any any
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacc8c118, priority=12, domain=permit, deny=false
hits=1057422, user_data=0xa8afac80, cs_id=0x0, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacc60fc0, priority=0, domain=inspect-ip-options, deny=true
hits=1111950, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 4
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xab9031a8, priority=12, domain=ipsec-tunnel-flow, deny=true
hits=1103897, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 5
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
nat-control
match ip inside any outside 172.16.40.184 255.255.255.248
NAT exempt
translate_hits = 4, untranslate_hits = 1290
Additional Information:
Forward Flow based lookup yields rule:
in id=0xab6c5410, priority=6, domain=nat-exempt, deny=false
hits=4, user_data=0xab6c5350, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=172.16.40.184, mask=255.255.255.248, port=0, dscp=0x0
Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
nat-control
match ip inside any outside any
dynamic translation to pool 1 (External_Base [Interface PAT])
translate_hits = 363815, untranslate_hits = 25872
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaba517e0, priority=1, domain=nat, deny=false
hits=383246, user_data=0xaba51720, cs_id=0x0, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 7
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
nat-control
match ip inside any inside any
dynamic translation to pool 1 (No matching global)
translate_hits = 0, untranslate_hits = 0
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaba50228, priority=1, domain=host, deny=false
hits=205767, user_data=0xaba4fe10, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 8
Type: WEBVPN-SVC
Subtype: out
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xad091f30, priority=71, domain=svc-ob-tunnel-flow, deny=false
hits=312, user_data=0x5f12000, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=172.16.40.185, mask=255.255.255.255, port=0, dscp=0x0
Phase: 9
Type: WEBVPN-SVC
Subtype: in
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xac9a9690, priority=70, domain=svc-ib-tunnel-flow, deny=false
hits=312, user_data=0x5f12000, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=172.16.40.185, mask=255.255.255.255, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xacd6b6d8, priority=0, domain=inspect-ip-options, deny=true
hits=1094705, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 42436422, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_svc_ob_tunnel_flow
snp_fp_fragment
snp_ifc_stat
Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_svc_ib_tunnel_flow
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
Now the packet from the VPN client to the server is denied by the default any any ip deny rule, but there is an any any accept rule in spot 1, so I am really confused as to why that is.
10-12-2014 07:10 AM
OK, thanks.
So your clients are being assigned addresses from:
ip local pool VPNTestPool 172.16.40.185-172.16.40.190 mask 255.255.252.0
You've exempted that pool from NAT with the last entry in your nonat acl:
access-list nonat extended permit ip any 172.16.40.184 255.255.255.248
One possible issue I see is that pool is a subnet carved out of your internal network:
ip address 172.16.40.2 255.255.252.0
The ASA will believe hosts in that subnet to be connected and your core may be confused about how to route them.
Also, I don't see where you set the
sysopt connection permit-vpn
...command recommended in the configuration guide you followed.
Also. in your first packet-tracer, the source for the VPN client traffic should be outside, not inside.
10-12-2014 10:12 AM
Okay, so I've changed the pool to 172.16.180.0 255.255.255.0 and now I can access everything, thanks!
10-12-2014 10:26 AM
You're welcome. Thanks for the rating.
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: