cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2228
Views
0
Helpful
9
Replies

Remote access vpn session cant talk to inside interface

aguy
Level 1
Level 1

Hi there.  Sorry this is yet another I cant talk to the inside interface post but im stuck.  My issue is with talking to traffic behind the inside interface once vpned into a test asav running 9.6(2)1.  Ive tried some of the suggestions in other threads like:

-https://www.fir3net.com/Firewalls/Cisco/cisco-asa-83-no-nat-nat-exemption.html (tried using the post 8.3 commands but nothing)

-https://supportforums.cisco.com/discussion/13229451/cisco-asa-remote-ipsec-vpn (pre 8.3 so doent apply)

-https://supportforums.cisco.com/discussion/13229666/i-cannot-ping-anyconnect-client-i-can-ping-inside-network (cant get it to work)

-etc

but still cant get it working and im getting frustrated. I can talk to the internal networks from the asa itself - eg asa# ping inside 10.1.1.1 no problem.  I can only ping the management and outside interface static ips (10.100.192.60, 10.100.194.60) form the vpn.  When I do a packet trace from a vpn client perspective I get:

packet-tracer input outside icmp 192.168.50.1 0 8 10.100.32.54 xml

-> result: type vpn, subtype ipsec-tunnel-flow, action drop; info (acl_drop_ flow is denied by configured rule

Anyone have an explanation step by step on how to configure this properly?  Im still getting familiar on how natting/acls/cryptomaps are applied in asa land.  Ive rolled back all my experimental changes so the nats and acls are blank.

Thanks,

Config attached.

9 Replies 9

Francesco Molino
VIP Alumni
VIP Alumni

Hi 

Can you provide the output of the following command in a text file?

packet-tracer input inside icmp 10.100.32.54 8 0 102.168.50.1 detail

Thanks 

PS: Please don't forget to rate and mark as correct answer if this answered your question


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

asav-test3# packet-tracer input inside icmp 10.100.32.54 8 0 192.168$

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

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static vpn_client vpn_client no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.50.1/0 to 192.168.50.1/0

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7ff9a4597ed0, priority=13, domain=permit, deny=false
    hits=3, user_data=0x7ff9bc418d00, 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=inside, output_ifc=any

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static vpn_client vpn_client no-proxy-arp route-lookup
Additional Information:
Static translate 10.100.32.54/0 to 10.100.32.54/0
 Forward Flow based lookup yields rule:
 in  id=0x7ff9b10c4020, priority=6, domain=nat, deny=false
    hits=1, user_data=0x7ff9b17b8880, cs_id=0x0, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
    dst ip/id=192.168.50.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
        input_ifc=inside, output_ifc=outside

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7ff9b10b3f80, priority=0, domain=nat-per-session, deny=true
    hits=6644, user_data=0x0, cs_id=0x0, reverse, 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=any, output_ifc=any

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7ff9a458aca0, priority=0, domain=inspect-ip-options, deny=true
        hits=12445, 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, tag=any
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
    input_ifc=inside, output_ifc=any

Phase: 7
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7ff9a458a4d0, priority=66, domain=inspect-icmp-error, deny=false
    hits=4, user_data=0x7ff9a4589a50, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
    src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=any
    dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=any, dscp=0x0
    input_ifc=inside, output_ifc=any

Phase: 8
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7ff9a46150b0, priority=70, domain=encrypt, deny=false
    hits=122, user_data=0x12614, cs_id=0x0, reverse, flags=0x0, protocol=0
    src ip/id=10.0.0.0, mask=255.0.0.0, port=0, tag=any
    dst ip/id=192.168.50.1, mask=255.255.255.255, port=0, tag=any, dscp=0x0
    input_ifc=any, output_ifc=outside

Phase: 9
Type: ACCESS-LIST
Subtype: filter-aaa
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7ff9b17b05e0, priority=13, domain=filter-aaa, deny=false
    hits=2, user_data=0x7ff9bc418280, filter_id=0x6(acl_net-admin), protocol=0
    src ip=10.0.0.0, mask=255.0.0.0, port=0
    dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 10
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static vpn_client vpn_client no-proxy-arp route-lookup
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7ff9b17c66a0, priority=6, domain=nat-reverse, deny=false
    hits=2, user_data=0x7ff9b10c32b0, 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=192.168.50.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
    input_ifc=inside, output_ifc=outside

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 12556, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_inspect_icmp
snp_fp_translate
snp_fp_adjacency
snp_fp_encrypt
snp_fp_fragment
snp_ifc_stat

Module information for reverse flow ...

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

asav-test3#

What are you trying to ping on the inside?  If you are trying to ping the ASA inside interface this will not work.  To get this to work you need to change the management-access command to reference the inside interface and not the management interface.

If you are trying to ping something on the inside network and this is a windows machine, make sure that the windows firewall is turned off while testing, or atleast that it allows ICMP.

--

Please remember to select a correct answer and rate helpful posts

--
Please remember to select a correct answer and rate helpful posts

Francesc:

inside asa interface: 10.100.193.1

outside asa interface: 10.100.192.1

client vpn pool: 192.168.50.0/24

im trying to talk over my client vpn session to a box behind the inside asa interface.  So its client vpn -> external ip -> outside asa interface -> inside asa interface -> host behind inside interface.   For packet tracer its:

packet-tracer input <source interface> <protocol> <source IP> <source port> <destination IP> <destination port> [detailed]

so wouldnt the command be:

packet-tracer input outside icmp 192.168.50.1 0 8 10.100.32.54 detailed

attached log of attempt to 10.100.32.54 (host behind inside) and inside itself.  Both resulted in Drop-reason: (acl-drop) Flow is denied by configured rule.

Marius:

Im trying to ping anything behind the inside interface and the interface itself from client vpn.  eg: any traffic from 192.168.50.1 -> any -> 10.100.193.1 (asav inside) or 10.100.32.54 (windows host) or anything else in there.  I dont think the management-access command has anything to do with this.  Isnt it just for management interfaces and access to the asa itself?

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/access_management.html#wp1064497

Im trying to pass traffic past it as a regular client user that has wide open access right now for testing.  There arent any firewalls on the windows machines and I know the traffic works since I can ping from the asa inside interface itself and it doesnt get blocked.  That also verifies my routes.

eg:

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

Hi 

We always use packet-tracer from inside to outside. The output you paste from outside to inside could be an expected behavior if asa isn't able to reach you're outside ip tested. Does a client was connected with the same ip pool IP when you've done the test?

Another test could be trying to ping you're vpn host from inside to see if it's working

Thanks.


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Im the only one testing vpn as a client from an outside ip so yes it will always be 192.168.50.1 for now.  Pinging the client from the outside works but inside doesnt.

asav-test3# ping inside 192.168.50.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.50.1, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
asav-test3# ping outside 192.168.50.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.50.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 90/96/110 ms
asav-test3#

I meant point anyconnect client from inside host not asa. While you're doing ping, can you take a look on logs and drop those logs? 

Thanks


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

I dont think the management-access command has anything to do with this.  Isnt it just for management interfaces and access to the asa itself?

It is just for management access to an interface over VPN...but, if you do not have it enabled for an interface you will NOT be able to ping that interface over the VPN.  So if you do not have management-access inside configured then you will not be able to ping the actual ASA inside interface.

change change the management-access command to management-access inside. If you are now able to ping the inside interface then your VPN is working fine and it is most likely a routing issue.  since this is a lab setup I am assuming you are using routers or a loopback interface to simulate hosts? is this a physical lab or a virtual lab?

Now, for you to be able to use packet-tracer to test the AnyConnect VPN, then you need to already have the VPN established before you test since you are not able to pull up the VPN from the ASA.  It is not like when testing site to site VPNs.

With regard to packet-tracer, it is not only used for inside to outside, but also from outside to inside. This really depends on what you are testing.  When we are testing VPNs it will always be inside to outside since we are not able to simulate an encrypted packet in packet-tracer.

--

Please remember to select a correct answer and rate helpful posts

--
Please remember to select a correct answer and rate helpful posts

Hi 

This is a capture from 2 machines and it shows that everything is working fine. 

You need to validate your end device ID something is blocking traffic or between the machine and the firewall (maybe a switch with an acl?)

Let us know. 

Thanks 

PS: Please don't forget to rate and mark as correct answer if this answered your question


Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
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: