Solved: AnyConnect clients can't access external sites

sysadmin · ‎06-10-2010

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.

Federico Coto Fajardo · ‎06-10-2010

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.

View solution in original post

Federico Coto Fajardo · ‎06-10-2010

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.

sysadmin · ‎06-10-2010

Thanks for the reply.

If I add:

nat (outside) 1 10.1.1.0 255.255.255.0

AC clients can access External sites, but not IPSec tunneled sites.

If I remove that nat (outside) 1 10.1.1.0 255.255.255.0

AC clients can access IPSec tunneled sites, but not External sites.

I need both.

Federico Coto Fajardo · ‎06-10-2010

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.

sysadmin · ‎06-10-2010

Also, things i've tried...

Found nat-control was on, turned it off, no change

Added ACL for outside thinking the VPN traffic, though let through and of internal IP range, is still considered "outside" traffic...

access-list outside_access_in extended permit ip 10.1.1.0 255.255.255.0 any

zeeahmed123 · ‎07-19-2011

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

sysadmin · ‎06-10-2010

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?

sysadmin · ‎06-10-2010

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 Fajardo · ‎06-10-2010

Correct :-)

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

Thank you,

Federico.

sysadmin · ‎06-10-2010

Thanks for your answer.. I think i was getting there at the same time you were replying. Your point about doing the nat (outside) 1 (actually from a previous thread) was the seed that got me there.

Johannes Herlitz · ‎02-05-2013

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!