ASA Control Plane

[Spagsterj]

Hello,

I'm attempting to limit what IP addreses can connect to an ASA using the SSL VPN. I would have thought control-plane policing would have worked, however it did not.

Here is what I configured:

access-list vpn_control extended permit tcp object-group allowed_clients interface outside

!

access-group vpn_control in interface outside control-plane

any suggestions would be appreciated.

Thanks!

[Marius Gunnerud]

Do you still require assistance with this issue?  If not please rate the helpful posts.

[jumora]

If you rate we assist if not black list

[davidkuhlman]

I'm having a problem which I think is described here.  I would essentially like to whitelist networks for ssl anyconnect vpn access.  I understand that the anyconnect client would attempt a connection to my outside interface on 443 and that it would be considered "to the box traffic" which would bypass the interface ACL's. I set up an acl to deny traffic from a specific test network to test the control plane option.  At first I tried 443 traffic and later expanded it to a deny any from the external network, but in either case I was still able to VPN to the asa from this test network using the anyconnect client.  I assume this has something to do with management traffic having priority and not distiguishing between managment traffic destined for /admin and ssl vpn connections.  However, I do not have the outside interface enabled as a management interface, so even that is a little puzzling.

access-list outside_access_in_1 extended deny ip object test_network any

access-list outside_access_in_1 extended permit ip any any

access-group outside_access_in_1 in interface outside control-plane

If I do a packet trace for 443 traffic from that network to my outside interface IP it does show the traffic passing and the ACL section specifically shows it passing via implicit rule...

[Julio Carvajal]

Hello,

Let me work on this and Get back to you,

Looking for some Networking Assistance? 
Contact me directly at jcarvaja@laguiadelnetworking.com

I will fix your problem ASAP.

Cheers,

Julio Carvajal Segura
http://laguiadelnetworking.com

[John.Syd.Aus]

I had the same problem too and figured out a solution. The problem being the control plane ACL is not blocking traffic from hosts residing on the non whitelist networks. In other words there is no permit statement covering connection from the unwanted host but unwanted host are still able to bypass the ACL and make connection directly to the box/ASA.

access-list ssl2box extended permit object tcp-883 202.144.2.0 255.255.255.0 any 

access-group ssl2box in interface outside control-plane

To clarify a few things in my particular setup:

• For webvpn ssl the ASA5505 is listening on non standard port (for example tcp/883)
• For http server management (only allowed for access from hosts residing behind the internal interface) the firewall is listening on tcp/444
• For my internal hosted site (sits behind ASA5505) I'm performing port forward (tcp/443) from outside interface IP to internal IP. 

What worked for me is adding in the explicit deny:

access-list ssl2box extended deny object tcp-883 any interface outside log 

Viewing the access list hits shows what happens when a connection attempt is made from an IP not permitted (i.e. not on the whitelist):

access-list ssl2box line 7 extended deny tcp any interface outside eq 883 log informational interval 300 (hitcnt=1) 0xb35c358c 

Strangely, implicit deny for the control-plane ACL did bugger all !

Interested to hear if this post has helped anyone..