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..?
Forward Flow based lookup yields rule:
in id=0x78e03140, priority=11, domain=permit, deny=true
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
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:
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:
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :