Cannot reach VPN Clients from Internal?

[alistair.cowan]

Hi Folks,

I have an ASA 5510 (8.2.1) set up with IPSEC VPN clients and am having a strange issue getting two-way connectivity in place.  High level configuration as follows:

Networks

Internal_Network (user desktops, servers, etc; hangs off a 48-gbport L3 switch): 10.84.0.0/255.255.0.0

Transit_Network (between ASA, and L3 switch): 192.168.84.0/255.255.255.224

DMZ (hangs off ASA): 172.16.84.0/255.255.255.0

VPN (ASA IP Pool): 172.16.85.0/255.255.255.0

Cisco Interfaces

outside 1.2.3.4/255.255.255.224

dmz 172.16.84.1/255.255.255.0

inside (on Transit_Network) 192.168.84.1/255.255.255.224

So, I have VPN clients connecting to the ASA, getting an IP 172.16.85.x from an IP Pool.  These clients are able to connect to specified servers on the internal 10.84.x.x network OK, so everything is fine in the VPN --> Internal direction, including ICMP.

However, in the direction of Internal --> VPN, I can only seem to get ICMP to work, for some reason....

The ipsec_vpn_access_systems list has the following ACL, which I thought should do the trick:

access-list ipsec_vpn_access_systems remark TEMP_TEST - Trying to get Internal --> VPN functioning...

access-list ipsec_vpn_access_systems extended permit ip int_InternalLAN 255.255.0.0 object-group vpn_VPNClientSystemsGroup 

No luck however...

6

Nov 18 2010

12:05:48

109025

10.84.6.37

51680

vpn_VPNClientSystemsIP0

3389

Authorization denied (acl=ipsec_vpn_access_systems) for user '' from 10.84.6.37/51680 to vpn_VPNClientSystemsIP0/3389 on interface inside using TCP

The only way I can get Internal --> VPN communication to work at all is to change the above ACL to any,any; which is obviously not an acceptable workaround...

There's also a NAT exemption in place between 10.84.x.x and 172.16.85.x.x:

access-list int_transit_nat0_outbound remark NAT exemption INTERNAL <--> DMZ.
access-list int_transit_nat0_outbound extended permit ip int_InternalLAN 255.255.0.0 dmz_DMZNetwork 255.255.255.0 

I've attached a sanitised version of my current configuration, would someone mind taking a look to see if I'm missing something obvious?  Apologies if it is difficult to read - this is a recent deployment and a work in progress; as soon as this final outstanding issue is resolved I'll be going through tidying locking down and tidying up the entire configuration.

Many thanks,
Alistair

[Federico Coto Fajardo · Accepted solution]

Hi,

It seems the error that you're having is caused by the ACL

ipsec_vpn_access_systems
Which is used as a VPN filter. 

Only traffic permitted in that ACL will be allowed through the tunnel. 
The connection shown is a TCP connection from the internal host 10.84.6.37 to the VPN client on destination port 3389. 

I don't think I see that statement in the ACL above. 
Could you verify that? 

Federico.

[alistair.cowan]

Hi Federico,

Thanks for your reply.

If you look above, there is a test ACE I've setup in ipsec_vpn_access_systems, which I believe should provide this access:

access-list ipsec_vpn_access_systems remark TEMP_TEST - Trying to get Internal --> VPN functioning...

access-list ipsec_vpn_access_systems extended permit ip int_InternalLAN 255.255.0.0 object-group vpn_VPNClientSystemsGroup

10.84.6.37 is included as part of int_InternalLAN 255.255.0.0:

name 10.84.0.0 int_InternalLAN description Entire Internal LAN

And the IP address of the VPN client I'm attempting to connect to from 10.84.6.37 is included within the following:

name 172.16.85.249 vpn_VPNClientSystemsIP0 - target IP address

name 172.16.85.250 vpn_VPNClientSystemsIP1

name 172.16.85.251 vpn_VPNClientSystemsIP2

name 172.16.85.252 vpn_VPNClientSystemsIP3

name 172.16.85.253 vpn_VPNClientSystemsIP4

name 172.16.85.254 vpn_VPNClientSystemsIP5

name 172.16.85.255 vpn_VPNClientSystemsIP6

object-group network vpn_VPNClientSystemsGroup - consists of the above network objects

network-object host vpn_VPNClientSystemsIP0

network-object host vpn_VPNClientSystemsIP1

network-object host vpn_VPNClientSystemsIP2

network-object host vpn_VPNClientSystemsIP3

network-object host vpn_VPNClientSystemsIP4

network-object host vpn_VPNClientSystemsIP5

network-object host vpn_VPNClientSystemsIP6

Let me explain the above.  As I mentioned, DMZ is 172.16.85.0/255.255.255.0.  However, I have split this range up using two different VPN IP Pools: 172.16.85.0 - .248 is for "standard" VPN users; and 172.16.85.249 - 255 is a small subset of IPs for "Systems Admin" VPN users, which allows me to assign a looser remote administration ACL for sysadmin users only..

Anyway, in summary, the above ACL should allow all IP traffic from 10.84.6.37 (int_InternalLAN) to 172.16.85.249 (aka. vpn_VPNClientSystems0, within vpn_VPNClientSystemsGroup); so I don't see why the TCP traffic is being denied?

Any help appreciated!

Thanks,

Alistair

[Federico Coto Fajardo · Accepted solution]

You mentioned that if you allow IP in the ACL then it works... this means that definitely this ACL is not permitting the traffic as it is...

As a test can you do the following and make this two lines the first statements in your ACL:

access-list ipsec_vpn_access_systems extended permit ip int_InternalLAN 255.255.0.0 object-group vpn_VPNClientSystemsGroup

access-list ipsec_vpn_access_systems extended permit ip object-group vpn_VPNClientSystemsGroup int_InternalLAN 255.255.0.0

I just include the mirror ACE since the VPN filters requiere the permissions to be specified in both directions.

Let's see if this fixes the problem... and if it happens again do a Packet-Tracer

packet-tracer input inside tcp x.x.x.x 1024 y.y.y.y 3389 det

x.x.x.x --> IP of the internal host

y.y.y.y --> IP of the VPN client (assigned from the pool)

Let's check the results to see if Packet-Tracer reports that it's being denied by the above ACL as well.

Federico.

[alistair.cowan]

Hi Federico,

Adding in that second mirrored ACE allowing VPN --> (IP) --> Internal worked!

That leaves me somewhat confused!  This log entry very clearly states that the traffic in the direction of Internal --> VPN was being denied (despite the fact a ACE for that traffic already existed):

6

Nov 18 2010

19:19:03

109025

int_vmINFRA-DC1

62306

vpn_VPNClientSystemsIP0

3389

Authorization denied (acl=ipsec_vpn_access_systems) for user '' from int_vmINFRA-DC1/62306 to vpn_VPNClientSystemsIP0/3389 on interface inside using TCP

I'm confused as to why return VPN --> Internal traffic is being denied in this particular case?  Also, why is the log saying Internal --> VPN traffic was denied, when in reality, it's the return traffic that's being denied?

Thanks for your help so far!

Alistair

[Federico Coto Fajardo]

It's because the perspective of the ACL used in the VPN-filter command.

Check the explanation here:

http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/vpngrp.html#wp1134794

Scroll down till you see the vpn-filter usage.

Federico.

[alistair.cowan]

Federico,

Thanks for the link; I got sorted using the reverse rules as described in that document...

access-list ipsec_vpn_access_systems extended permit tcp int_InternalLAN 255.255.0.0 object-group vpn_VPNClientSystemsGroup eq 3389
access-list ipsec_vpn_access_systems extended permit tcp object-group vpn_VPNClientSystemsGroup eq 3389 int_InternalLAN 255.255.0.0 

I certainly don't find this setup very intuitive/flexible/secure, especially when attempting to open multiple protocols/ports to get a single service running (one prime example being accessing MS File Sharing on the VPN clients from the internal network), however I'm no Cisco expert so that's probably to be expected...

Thanks,
Alistair

[Federico Coto Fajardo]

Alistar,

I actually agree with you 100%.

I don't like the vpn-filter ACLs either :-)

I'm no Cisco expert either.... just trying to help whenever I can.

Federico.