topic ASA Control Plane in Network Security

ASA Control Plane

Spagsterj — Tue, 12 Mar 2019 03:04:08 GMT

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!

ASA Control Plane

jumora — Thu, 14 Nov 2013 14:35:27 GMT

Please post more of the configuration and check logs to see what you are reporting, by any chance do you have http server enable, can you get me a show run http.

Check the following link that contains and explanation:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/a1.html#wp1541842

Note Access control rules for to-the-box management traffic (defined by such commands as http, ssh, or telnet) have higher precedence than an access list applied with the control-plane option. Therefore, such permitted management traffic will be allowed to come in even if explicitly denied by the to-the-box access list.

Re: ASA Control Plane

Marius Gunnerud — Thu, 14 Nov 2013 20:12:10 GMT

The command you entered for the control plane is for traffic destined for the ASA itself...but also VPN traffic will bypass the interface ACLs as it is encrypted by default.

You could try to issue the command no sysopt connection permit-vpn this will require the ASA to check the SSL VPN traffic against the interface configured ACL

Please rate any helpful posts.

ASA Control Plane

jumora — Thu, 14 Nov 2013 21:21:58 GMT

This would be for traffic through the ASA and not really to the ASA.

sysopt connection permit-vpn

The sysopt connection permit-ipsec command allows all the traffic that enters the security appliance through a VPN tunnel to bypass interface access lists. Group policy and per-user authorization access lists still apply to the traffic. In PIX/ASA 7.1 and later, the sysopt connection permit-ipsec command is changed to sysopt connection permit-vpn. The vpn-filter is applied to post-decrypted traffic after it exits a tunnel and pre-encrypted traffic before it enters a tunnel.

ASA Control Plane

Marius Gunnerud — Thu, 14 Nov 2013 22:04:32 GMT

Yes I know, but it is a option none the less

ASA Control Plane

Julio Carvajal — Thu, 14 Nov 2013 22:21:10 GMT

Hello,

Agree, The option to go is the control-plane one.

As far as I am aware that should do it.

Example:

access-list outside-control-plane extended deny tcp host 1..1.1.1 x.x.x.x eq 443 (where x.x.x.x is the Out interface IP)

access-group outside-control-plane in interface outside control-plane

Rate all of the helpful posts!!!

Regards,

Jcarvaja

Follow me on http://laguiadelnetworking.com

ASA Control Plane

jumora — Thu, 14 Nov 2013 23:23:36 GMT

Check the following link that contains and explanation:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/a1.html#wp1541842

ASA Control Plane

Marius Gunnerud — Fri, 15 Nov 2013 09:25:21 GMT

@ jumora - you are correct, however this is only applicable for managment traffic. To me it sounds like Spagsterj wants to limit IPs that are able to initiate an SSL VPN session. As PKI will exchange keys before any traffic is sent between the devices, the traffic will be encrypted when the actual connection is made and will therefore bypass the outside interface ACL by default. So (unless my logic is completely off here) he will need to disable the ACL bypass for it to take effect.

ASA Control Plane

jumora — Fri, 15 Nov 2013 22:50:23 GMT

That is the issue, the ASA does not distinguish this if it is SSL VPN or management, I work at TAC and escalated a ticket a couple of days due to this, it is also related to class type management that did not work for SSL traffic but did for SSH.

Believe me I know what I'm talking about.

ASA Control Plane

Julio Carvajal — Sat, 16 Nov 2013 07:31:03 GMT

Hello Marius,

Agree with Juancito "loquillo" in this one as what the customer is trying to accomplish is filter who connects to the Firewall via SSL, not what traffic is allowed to go via the tunnel.

In this case the control-plane option is the suitable option.

Cheers to boh of you.

Rate all of the helpful posts!!!

Regards,

Jcarvaja

Follow me on http://laguiadelnetworking.com

ASA Control Plane

Marius Gunnerud — Sat, 16 Nov 2013 16:32:54 GMT

Hi Julio,

That is my understanding too. I don't think I mentioned traffic filtering...or did I? I will have a read through the posts and see.

Anyway, I am wondering if perhaps the ACL assigned to the control plane is being bypassed due to the encryption, which is why I suggested trying to disable the interface ACL bypass by using the following command:

no sysopt connection permit-vpn

ASA Control Plane

jumora — Sun, 17 Nov 2013 05:28:50 GMT

Ok, do you still need assistance?

Julio knows me and please believe me when I correct anyone it´s not to presume it´s because I want them to understand.

Customer to you still need assistance???

ASA Control Plane

Marius Gunnerud — Tue, 19 Nov 2013 17:49:42 GMT

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

ASA Control Plane

jumora — Tue, 19 Nov 2013 17:55:31 GMT

If you rate we assist if not black list

ASA Control Plane

Spagsterj — Tue, 14 Jan 2014 19:40:55 GMT

Hello,

Has there been any change regarding filtering what source IP address can initiate an SSL connection to the ASA for VPN access?

ASA Control Plane

davidkuhlman — Fri, 17 Jan 2014 16:34:59 GMT

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...

Re: ASA Control Plane

Kevin Shipley — Tue, 04 Mar 2014 04:01:02 GMT

Bbb

Sent from Cisco Technical Support iPhone App

Re: ASA Control Plane

Julio Carvajal — Tue, 04 Mar 2014 13:07:14 GMT

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

I had the same problem too

John.Syd.Aus — Thu, 19 Jan 2017 09:36:52 GMT

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..

Re: ASA Control Plane

Jack G — Thu, 03 Jun 2021 15:21:09 GMT

This appeared to work for me. Persistent SSL VPN connections attempts are now denied from the source IP.