I've just constructed a very small, very specific policy-map for the first time on our ASA 5510 and I wanted to run it by you all to tell me what I am doing wrong (I am sure I've messed something up) and how I can resolve it.
The use case is that I would like to limit the number of simultaneous connections from a single client to our web server at one time. Here is what I have constructed:
# I constructed this ACL to identify traffic that was directed at our web server from only the outside, not from the outside (the 192. and 10. networks being used as the inside and Google's DNS used as the web server in this example).
access-list WEB_SERVER_TRAFFIC extended deny ip 192.168.0.0 255.255.0.0 any
access-list WEB_SERVER_TRAFFIC extended deny ip 10.0.0.0 255.0.0.0 any
access-list WEB_SERVER_TRAFFIC extended permit ip any 188.8.131.52 255.255.255.255
# Create class-map and match the ACL.
match access-list WEB_SERVER_TRAFFIC
# Create policy map, set limits, and apply to the outside interface on the firewall.
set connection per-client-embryonic-max 25 per-client-max 50
service-policy CONNECTION_LIMITS interface outside
Also, if anyone has any input on how to properly test and make sure this policy-map is working, that would be awesome. I appreciate any input, criticism, insults, whatever. Thanks.
Thanks for the reply! The reason I built the ACL in this way is because I want the policy to apply when *anyone* accesses the web server from the outside, but not if they are accessing it from the inside. I may have been a little unclear about this by saying "from a single client"; what I meant was, for each client that connects to the web server, I want to limit the number of simultaneous connections they are able to make.
Ok, in that case it makes sense if the IP 184.108.40.206 is an example IP address of your Web server. Though you could write it "host 220.127.116.11" without needing to mention the mask.
I think there might be a difference in the ACL Configuration depending on your software. I am not 100% sure.
I am using a newer 8.4 software which already has the new NAT configuration format. In my test configuration (same as yours above) I had to configure the destination IP address as the local IP address of the server and not use the public NAT IP address of my server.
In my own ASAs case I think its because of the new software level.
Since when a connections is coming to my server with public IP address through Static NAT, the UN-NAT is done first. What I mean is the public IP address is untranslated to the local IP address of the server and only then the ASA matches the configurations on the "policy-map" configurations. Or atleast that is how it seems.
I am not sure what the thing is in the older software levels.
So might depend on your software level. The bigger change regarding the NAT happened with the jump from 8.2 software to 8.3.
You can use the "packet-tracer" command to test and confirm that the policy is applied. It will show up in the output.
If you are not familiar with the "packet-tracer" you should try it. Its a great tool to simulate a packet entering the ASA and seeing which configurations are applied to it or apply to it.
packet-tracer input outside tcp 18.104.22.168 12345 80
After adding the actual public IP address to the above command you could simulate a packet coming towards your Web server with the destination port TCP/80. The packet would be coming with a source address of 22.214.171.124 and source port of TCP/12345
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...