AnyConnect clients can't access external sites

Answered Question

I'm looking to setup AnyConnect VPN with no split tunneling. ASA 5505 v8.2. It seems this should be really easy. I must be missing something.


I can get the AnyConnect users to connect fine and they can access sites internal and at other IPSec-tunneled sites. But no access to the internet.


Internal is 10.1.1.x, VPN pool is 10.1.1.251-253 (Temp list for testing). I issued the following tracer:

packet-tracer input outside tcp 10.1.1.253 12345 69.147.125.65 80 detailed


The last reported point (where it fails) is:



Phase: 7

Type: WEBVPN-SVC

Subtype: in

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xda7e9808, priority=70, domain=svc-ib-tunnel-flow, deny=false

     hits=364, user_data=0xcb000, cs_id=0x0, reverse, flags=0x0, protocol=0

     src ip=TempVPNPool3, mask=255.255.255.255, port=0

     dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0



What does it mean by WEBVPN-SVC?


Some relevant config:


No ACL, filters or group policy limitations on AC clients.

same-security permit intra-interface

global (outside) 1 interface



On advice I added: nat (outside) 1 10.1.1.0 255.255.255.0, then I can get outside hosts, but then no IPSec tunneled hosts.

Whats odd is that with this change, the packet tracer doesn't change. Still shows deny, yet the site is reachable.



Correct Answer by Federico Coto F... about 7 years 1 month ago

When you say IPsec tunneled sites.. is that Site-to-Site IPsec tunnels on the ASA?


The command:

nat (outside) 1 10.1.1.0 255.255.255.0

is needed to allow the pool of AnyConnect clients to get PATed to the Internet.


If you need the AnyConnect clients to access the Internet and access remote IPsec tunnels as well, you can do it with Policy NAT:


access-list anyconnect deny ip 10.1.1.0 255.255.255.0 x.x.x.x

access-list anyconnect deny ip 10.1.1.0 255.255.255.0 y.y.y.y

access-list anyconnect permit ip 10.1.1.0 255.255.255.0 any


nat (outside) 1 access-list anyconnect

global (outside) 1 interface


With the above configuration, you are bypassing NAT for the AnyConnect clients when they want to access the remote sites through the IPsec tunnels (assuming x.x.x.x and y.y.y.y to be the remote networks through those tunnels).

And everything else from the AnyConnect pool (10.1.1.0/24) will be PATed to the Internet.


Federico.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Federico Coto F... Thu, 06/10/2010 - 12:07
User Badges:
  • Green, 3000 points or more

Hi,


WEBVPN-SVC is the actual SSL VPN client (AnyConnect)


To allow VPN clients to get out to the Internet through the ASA you need to NAT/PAT (seems you got it working now).


What seems to be the problem that you're having now?


Federico.

Correct Answer
Federico Coto F... Thu, 06/10/2010 - 12:46
User Badges:
  • Green, 3000 points or more

When you say IPsec tunneled sites.. is that Site-to-Site IPsec tunnels on the ASA?


The command:

nat (outside) 1 10.1.1.0 255.255.255.0

is needed to allow the pool of AnyConnect clients to get PATed to the Internet.


If you need the AnyConnect clients to access the Internet and access remote IPsec tunnels as well, you can do it with Policy NAT:


access-list anyconnect deny ip 10.1.1.0 255.255.255.0 x.x.x.x

access-list anyconnect deny ip 10.1.1.0 255.255.255.0 y.y.y.y

access-list anyconnect permit ip 10.1.1.0 255.255.255.0 any


nat (outside) 1 access-list anyconnect

global (outside) 1 interface


With the above configuration, you are bypassing NAT for the AnyConnect clients when they want to access the remote sites through the IPsec tunnels (assuming x.x.x.x and y.y.y.y to be the remote networks through those tunnels).

And everything else from the AnyConnect pool (10.1.1.0/24) will be PATed to the Internet.


Federico.

zeeahmed123 Tue, 07/19/2011 - 04:38
User Badges:

Hi Matthew,


I saw this post and have a similar issue; my Cisco anyconnect VPN clients are able to access all of my internal networks accept to another site which has a IPSEC VPN site-to-site. The Cisco ASA forwards the packets destined to this remote site to a Cisco router which NATS the source addresses (pool 10.17.252.0/24) to a 192.168.46.0 range. The remote network is 155.x.x.x which I have included in my internal subnets object-group and added a route on the ASA to route it inside.


I have configured NAT so that it does not NAT anything from the anyconnect client range to the internal subnets. I am using version 8.3(2) and the NAT rule is:


nat (outside,inside) source static SSLPOOL SSLPOOL destination static INSIDE_NETS INSIDE_NETS


I can still not connect to the remote side via the VPN; when I run this throught packet-tracer, I get a failure on phase 6:

Type: WEBVPN-SVC

Subtype: in

Result: DROP


Result:

Drop reason: (acl-drop) Flow is denied by configured rule

So wait...

If I have to nat0 my internal traffic headed to the IP-sec sites on the inside interface....



global (outside) 1 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 0.0.0.0 0.0.0.0 dns

nat (outside) 1 10.1.1.0 255.255.255.0

Does it follow that I need to nat0 the 10.1.1.1 range on the outside interface as well?

WOOT!


It worked.


They key point for me is understanding that VPN client traffic is internally addressed (10.1.1.x) but is "on" the outside interface. Any nat rules for that internal range on the inside interface will not get applied to VPN client traffic. And it turns out a few should.


So with not having a nat on the outside interface for my internal IP range (by accident of omission), those IP's would reach my IPSec tunnels just fine. Makes sense as I explicitly exempt nat'ing between my internal addresses and ipsec ranges anyway.


But I could not reach external internet sites. I'm looking to not do split tunneling for security reasons. When adding the nat (outside) 1 10.1.1.0 255.255.255.0 that got me access to external sites. Makes sense, a 10.1.1.x address needs a nat, no matter where it comes from. But then all my ipsec sites did not work. Grrr.


light bulb comes on


If I'm now nat'ing all 10.1.1.x numbered traffic on my outside interface, I should then have to explicitly exempt nat'ing for my ipsec tunneled addresses just as I do for the inside interface. I added nat (outside) 0 access-list inside_nat0_outbound and now IPsec tunnel traffic works and external traffic works!

Federico Coto F... Thu, 06/10/2010 - 13:33
User Badges:
  • Green, 3000 points or more

Correct  :-)

Please rate the post and mark it as answered (if you considered it helpful).


Thank you,


Federico.

Johannes Herlitz Tue, 02/05/2013 - 01:26
User Badges:

The ASA considering AnyConnect clients being on the outside, even after successful tunnel establishment wasnt obvious to me either. Now it is and I know how to build my NAT rules.

Thank you!

Actions

This Discussion