Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

AnyConnecy VPN and Split-tunnel ACL - Strange...

Hi,

I have ACL as follows and applied on AnyConnect VPN group as split-tunel value ACL.

access-list SPLIT-ACL extended permit tcp host 192.168.200.63 172.16.1.0 255.255.255.0 eq www

access-list SPLIT-ACL extended permit tcp host 192.168.200.63 172.16.1.0 255.255.255.0 eq https

When I connected with AnyConnect client, I can ping to 192.168.200.63 and also telnet to port 80. However I can not telnet to port 443. Strange thing is I do not see any hits on above ACL, morever I'm wondering how cam the ICMP is working and why it does not stop on this ACL..?

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x78e03140, priority=11, domain=permit, deny=true

        hits=113713, user_data=0x5, 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=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0

        input_ifc=outside, output_ifc=any

When I did the packet-tracer both ICMP and http it just drop on Phase 4..as bellow, I just want to know what this ACL and where its been applied to..?

What is the correct syntax for packet-tracer command when troubleshooting AnyConnect VPN to check access inside/dmz server..?

I have used as follows:

packet-tracer input outside icmp 172.16.1.1 0 8 192.168.200.63 details

Appreciate if someone can help me out on this..

thanks

7 REPLIES
New Member

AnyConnecy VPN and Split-tunnel ACL - Strange...

Hey pemasirid,

Are you trying to do a packet trace sourcing from Outside to the DMZ?

New Member

AnyConnecy VPN and Split-tunnel ACL - Strange...

Yes I was tring to do packet-trace from Outside to DMZ. is there any other way that we can use for packet-tracer for troublshoot remote access VPN

New Member

AnyConnecy VPN and Split-tunnel ACL - Strange...

If you are troubleshooting a remote access then you would need to do a packet-trace from inside to DMZ. Once the end user has gained a VPN connection then their are on the insde network. Also do a tracert (windows) or a traceroute (Linux) from the end user's PC to see where the traffic is going. Since you have split tunneling configured on the remote access I assume that the end user's traffic is going out their ISP link and not over the VPN (if that makes sense to you). I find it easier to just remove the split tunneling on remote access (webvpn), add whatever ACLs needed and confirm that there is a NAT exempt between the inside and DMZ (incoming and outgoing)

NAT EXEMPT EXAMPLE:

access-list nat_exempt_dmz extended permit ip 172.16.1.0 255.255.255.0 192.168.20.0 255.255.255.0

access-list nat_exempt_inside extended permit ip192.168.20.0 255.255.255.0172.16.1.0 255.255.255.0

nat (dmz) 0 access-list nat_exempt_dmz

nat (inside) 0 access-list nat_exempt_inside

New Member

AnyConnecy VPN and Split-tunnel ACL - Strange...

Hi Rashid,

Thanks for your reply and interest on this. I'm wondering how come the vpn traffic initating as Inside when it landed via outside interface. Do you have any document that explain packet-tracer using vpn user as outside interface.

I have already made that subnet for NAT excemption. (no-nat), but it is only with latest code as double nat as follows:

nat (DMZ,outside) source static vpn-local vpn-local destination static vpn-remote vpn-remote

vpn-local - DMZ server

vpn-remote - vpn pool subnet

here is some reference links

https://supportforums.cisco.com/docs/DOC-9129

https://supportforums.cisco.com/message/3168125#3168125

Cisco Employee

AnyConnecy VPN and Split-tunnel ACL - Strange...

To start with it is not ideal to configure a port based split tunnel. It is not support and will give you weird results like one you are experiencing. You should use standard access-list for the split tunnel and to restrict the users to the following port use vpn filter.

As far as packet tracer is concerned for the VPN client if you use the outside interface as source it will never work the reason is the connection between the ASA and the client is of real IP address (Public) and the traffic that you are testing with is a VPN encrypted traffic your ASA's outside interface doesn't know what is 172.16.1.1, he will check it against the outside access-list and will drop it.

So in your case i would strongly recommed that use standard access-list for the split tunnel and to restrict the user to specific port use vpn filter. Following are the links to configure the same:

Allow Split Tunnel for Anyconnect:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080975e83.shtml

Configure VPN filter (Its for site to site and remote access but it works the same for Anyconnect):

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml

Thanks

Jeet Kumar

New Member

AnyConnecy VPN and Split-tunnel ACL - Strange...

Hello Jeet,

Thanks for your reply and it looks sounds good on split-tunnel ACL and VPN filter. I will apply them and let you know the result.

Meanwhile I want to know what is the correct syntax to use packet-tracer for VPN users (source as VPN pool IP) or does packet-tracer will not work for troubleshooting VPN users.?

thanks

New Member

AnyConnecy VPN and Split-tunnel ACL - Strange...

When an end user has a VPN connection to the network they obtain an IP address from the VPN pool (ex: 172.16.1.0 - 100). This VPN pool lives in the ASA which is a part of the inside network. Therefore you will get a better result if you run the packet tracer on the inside interface.

Example:

packet-tracer input inside icmp 172.16.xxx.xxx 192.168.xxx.xxx details

523
Views
5
Helpful
7
Replies
CreatePlease to create content