Trouble restricting client VPN access

[Rex Biesty]

Hi

I'm trying to restrict a VPN client so that it can only access one device behind our firewall. I have implemented the following commands

ip local pool SCS_Nant_Pool 10.10.99.1 mask 255.255.255.255

tunnel-group SCS_Nant_Support type ipsec-ra

tunnel-group SCS_Nant_Support general-attributes

address-pool SCS_Nant_Pool

tunnel-group SCS_Nant_Support ipsec-attributes

pre-shared-key *******

access-list nonat extended permit ip host 128.6.100.112 host 10.10.99.1

where 128.6.100.112 is the device I want sole access of. When I connect I receive IP address 10.10.99.1 OK but cannot ping or connect to 128.6.100.112. If I use a different tunnel group I can access everything fine. Command for the working group are

ip local pool Vpn-Pool 128.7.0.1-128.7.0.100 mask 255.255.0.0

tunnel-group ras type ipsec-ra

tunnel-group ras general-attributes

address-pool Vpn-Pool

tunnel-group ras ipsec-attributes

pre-shared-key ********

access-list nonat extended permit ip LOCAL_NET 255.255.0.0 CSG_WAN 255.255.255.0

access-list nonat extended permit ip LOCAL_NET 255.255.0.0 host ICCHOST

access-list nonat extended permit ip LOCAL_NET 255.255.0.0 10.0.0.0 255.252.0.0

access-list nonat extended permit ip host 128.6.100.112 CSG_WAN 255.255.255.0

access-list nonat extended permit ip host 128.6.100.112 10.0.0.0 255.255.0.0

access-list nonat remark nat 0 for remote vpn users

access-list nonat extended permit ip any 128.7.0.0 255.255.0.0

access-list nonat extended permit ip host 128.6.100.112 10.1.0.0 255.255.0.0

I have used this method before on firewalls running 6.3 without issue but this firewall (running v7) is not working.

Any help would be greatly appreciated.

Thanks

Rex

[palomoj · Accepted solution]

I forgot about that entry. I don't see an outbound ACL hole for these two hosts.

access-list inside_out extended permit tcp host TALENT_SERVER host 10.10.99.1

[Rex Biesty]

Thanks for all your help. I took your advice and added the line

access-list inside_out extended permit ip host TALENT_SERVER host 10.10.99.1

and all is working fine now.

[acomiskey]

palomoj, I still don't get why this worked as he was initiating traffic from the remote end. The sysopt command would allow this traffic back out without the need for the acl right?

[palomoj]

The sysopt will permit the remote client vpn traffic to terminate and enter the outside interface without an outside ACL explicitly or implicitly permitting the traffic.

The inside ACL was denying the return (and initiating) traffic from the inside host to the remote VPN client.

HTH

[acomiskey]

Weird, I understand the initiating from the inside problem, but I could have sworn that the traffic bypassed all interface acl's, inside and outside.

When blocking the return traffic the firwall is basically not stateful anymore? If I accessed a webserver from the outside and had an inside access-list I would not have to have the return traffic permitted...I know you know this, just using it as an example.

access-list inside permit tcp webserver eq 80 any

[palomoj]

Its still stateful and always will be but an inside ACL blocking the outbound traffic results in blocked traffic. Here's a good explanation of the EXACT operations of the ASA.

1. A TCP SYN packet arrives at the PIX Firewall to establish a new connection.

2. The PIX Firewall checks the access control list (ACL) database to determine if the connection is permitted.

3. The PIX Firewall creates a new entry in the connection database (XLATE and CONN tables).

4. The PIX Firewall checks the Inspections database to determine if the connection requires application-level inspection.

5. After the application inspection function completes any required operations for the packet, the PIX Firewall forwards the packet to the destination system.

6. The destination system responds to the initial request.

7. The PIX Firewall receives the reply packet, looks up the connection in the connection database, and forwards the packet because it belongs to an established session.

Here's a link.

http://www.cisco.com/en/US/docs/security/pix/pix63/configuration/guide/fixup.html#wp1078381

[acomiskey]

Exactly, if the communication was initiated from the outside the conn would be built and the reply would be allowed, regardless of an inside acl.

I understand he would not be able to initiate from the inside, but this is not what he was trying to do. He was initiating traffic from the vpn client, which would have built the connection in the firewall and using the above, #7 would allow the reply to the vpn client in the inside interface, right or wrong?

[palomoj]

I think you're getting confused with the interface where the return traffic is entering. If the inside acl permits the outbound traffic, the ASA will allow the return traffic from the outside even if the outside ACL has a deny ip any any in it. If the traffic is permitted from the outside but the inside acl does not permit the return traffic, then you will not have a connection built.

[acomiskey]

"I think you're getting confused with the interface where the return traffic is entering"

-Nope. It depends on who is initiating the connection. If initiated from outside then the return traffic would be into inside interface and vice versa.

"If the inside acl permits the outbound traffic, the ASA will allow the return traffic from the outside even if the outside ACL has a deny ip any any in it."

-Yes, I understand that.

If the traffic is permitted from the outside but the inside acl does not permit the return traffic, then you will not have a connection built.

-Why? Isn't that what stateful is all about? If what you are saying is true then to hit a webserver on the inside from the outside I would need this...

access-list outside permit tcp any host webserver eq 80

access-group outside in interface outside

and...

access-list inside permit tcp webserver eq 80 any

access-group inside in interface inside

[palomoj]

well by default there is no inside acl so normally it would permitted if the outside acl permits and there is a static nat entry.

what's your email address? so we can take this offline.

[acomiskey]

Emailing you...

[Rex Biesty]

The only comments I've added are those listed at the beginning of my first post. However, my colleague (god bless him) may have. I think he tried to sort this out himself before enlisting my help (without any knowledge of Pix's). Alas I cannot contact him at the moment.