Access list issues

Hello,
There has been an access list in place where I work since well before I arrived and it doesn't quite work. I've done some research on ACLs and modified it so that it works better than it did before; however, it still doesn't do what was designed to do - block or "quarantine" devices so they are forced to update their systems with patches. It is also used to help in the baselining of pcs.
The access list works for the blocking portion, but it doesn't quite work for the baselining portion, meaning it currently succeeds in forcing the pcs to go to our server and get the latest patches but as a part of the baselining process, all machines have a policy that is pushed to them that maps a share drive. This is where the problem is - with the existing ACL, they can ping and see the share drive but they cannot access it. I've tried changing the permit ip statement to permit tcp but that just hoses the pc up and they get a "general failure" when trying to ping the share drive.
Here is access list:
ip access-list extended Quarantine_IN_L1
permit icmp any any
permit udp any any eq bootps
permit udp any any eq bootpc
permit upd any any eq domain
permit tcp any eq 3389 any
permit ip any host x.x.x.x (baseline server)
permit ip any host x.x.x.x (share drive)
permit ip any host x.x.x.x (domain controller)
permit ip any host x.x.x.x (domain controller)
ip access-list extended Quarantine_Out_L1
permit icmp any any
permit udp any any eq bootps
permit udp any any eq bootpc
permit udp any an any eq domain
permit tcp any any eq 3389
permit ip host (baseline server) any
permit ip host (share drive) any
permit ip host (domain controller) any
permit ip host (domain controller) any
As I said, I tried changing the permit ip host (baseline server) any and ip any host (baseline server) to permit tcp statements. That didn't work; then I modified it so there were both permit tcp and permit ip (baseline server) statements. That also didn't work.
Any help would be greatly appreciated as I've been working on this issue for almost a week now with nothing to show but bald spots where I've pulled my hair out!
Thanks,
Kiley

Paul,
When I remove the ACL, they can access the share drive so I figured it was something I've done wrong with the ACL. I'm not able to provide a topology diagram of the network unfortunately, but we do have a server subnet, user subnet - typical of a medium sized company, I would assume. The ACL is applied to the L3 interface for baselining:
int vlan 500
description BASELINE VLAN
ip addres x.x.x.x x.x.x.x
ip access-group Quarantine_IN_L1 in
ip access-group Quarantine_Out_L1 out
ip helper-address x.x.x.x
no ip redirects
no ip unreachables
no ip proxy-arp
Thanks,
Kiley

Similar Messages

Cisco ASR 1002- performance issue due to access list

Hi,
We are planning to implement inbound access-list to block subnets from particular country. Since the subnets are not contiguous, we have about 16000 lines of acl entries.
I want to know, would there be any performance or latency issues after applying 16k lines of acl?
Is there a good document where I can read more about ACL limitations and performance issues on ASR.
This is for ASR1002, running IOS-XE 15.3(1)S1.
Thanks

Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Sorry, I don't know the answer to your questions, but I'm writing to mention a 7200 feature, that if supported on the ASR, might help in your situation. See http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html#turbo

Remote access Vpn issue

Dear All,
I have configured remote access vpn without using split tunnel.Everything is working fine.I can access all the inside network which is allowed in acl.
I am facing strange issue now. I have created a pool for remote access vpn with a range 192.168.5.8/29.I can access my internal subnets 10.10.0.0/16.
I have below acess-list for acl-in.
access-list acl-in extended permit ip object-group vpnclients 192.168.5.8 255.255.255.248
object-group network vpnclients
network-object host 10.110.100.26
network-object host 10.106.100.15
network-object host 10.10.10.6
network-object host 10.10.20.82
network-object host 10.110.100.48
network-object host 10.10.20.53
network-object host 10.10.20.54
network-object host 10.60.100.1
network-object host 10.10.10.75
network-object host 10.10.20.100
network-object host 10.10.130.136
network-object host 10.106.100.16
network-object host 10.106.100.9
network-object host 10.170.100.1
network-object host 10.170.100.2
network-object host 10.170.100.21
network-object host 10.101.100.20
network-object host 10.170.100.25
So whichever IPs i have called in vpnclient group is able to access via RA vpn.Issue is when i try to access internal network of 192.168.198.0/24, i am able to access it without adding in vpnclient group. Even for 192.168.197.0/24,192.168.197.0/24 the same. But for 10.10.0.0/16 we can access only after adding in vpnclient group. Any one has face this issue before. Is this because of same network i mean 192.168.0.0 something like that.There is no other staement in acl-in for 192.168.0.0
Regards
-Danesh Ahammad

Hi,
If i read correctly you made the RA vpn "without" split tunnel, correct? if that is the case, all of the traffic will traverse the vpn connection (tunnel all) , the access-list "acl-in" is of no use to it.
try converting it to use split tunnel, i am sure that way you can not access resources that are not mentioned in the list.
~Harry

IOS XR deny ace not supported in access list

Hi everybody,
We´ve a 10G interface, this is a MPLS trunk between one ASR 9010 and a 7613, and the first thing that we do is through a policy-map TK-MPLS_TG we make a shape of 2G to the interface to the output:
interface TenGigE0/3/0/0
cdp
mtu 1568
service-policy output TK-MPLS_TG
ipv4 address 172.16.19.134 255.255.255.252
mpls
mtu 1568
policy-map TK-MPLS_TG
class class-default
service-policy TK-MPLS_EDGE-WAN
shape average 2000000000 bps
bandwidth 2000000 kbps
and we´ve the policy TK-MPLS_EDGE-WAN as a service-policy inside, this new policy help us to asign bandwidth percent to 5 class-map, wich in turn match with experimental values classified when they got in to the router:
class-map match-any W_RTP
match mpls experimental topmost 5
match dscp ef
end-class-map
class-map match-any W_EMAIL
match mpls experimental topmost 1
match dscp cs1
end-class-map
class-map match-any W_VIDEO
match mpls experimental topmost 4 3
match dscp cs3 cs4
end-class-map
class-map match-any W_DATOS-CR
match mpls experimental topmost 2
match dscp cs2
end-class-map
class-map match-any W_AVAIL
match mpls experimental topmost 0
match dscp default
end-class-map
policy-map TK-MPLS_EDGE-WAN
class W_RTP
bandwidth percent 5
class W_VIDEO
bandwidth percent 5
class W_DATOS-CR
bandwidth percent 30
class W_EMAIL
bandwidth percent 15
class W_AVAIL
bandwidth percent 2
class class-default
end-policy-map
what we want to do is to assign a especific bandwidth to the proxy to the output using the class W_AVAIL, the proxy is 150.2.1.100. We´ve an additional requirement, wich is not apply this "rate" to some networks we are going to list only 4 in the example, so what we did was a new policy-map with a new class-map and a new ACL :
ipv4 access-list PROXY-GIT-MEX
10 deny ipv4 host 150.2.1.100 10.15.142.0 0.0.0.255
20 deny ipv4 host 150.2.1.100 10.15.244.0 0.0.0.255
30 deny ipv4 host 150.2.1.100 10.18.52.0 0.0.0.127
40 deny ipv4 host 150.2.1.100 10.16.4.0 0.0.0.255
50 permit tcp host 150.2.1.100 any
60 permit tcp host 10.15.221.100 any
policy-map EDGE-MEX3-PXY
class C_PXY-GIT-MEX3
police rate 300 mbps
class class-default
end-policy-map
class-map match-any C_PXY-GIT-MEX3
match access-group ipv4 PROXY-GIT-MEX
end-class-map
we asign a policy rate of 300 mbps to the class inside the policy EDGE-MEX3-PXY and finally we put this new policy inside the class W_AVAIL of the policy TK-MPLS_EDGE-WAN
policy-map TK-MPLS_EDGE-WAN
class W_RTP
bandwidth percent 5
class W_VIDEO
bandwidth percent 5
class W_DATOS-CR
bandwidth percent 30
class W_EMAIL
bandwidth percent 15
class W_AVAIL
service-policy EDGE-MEX3-PXY
class class-default
end-policy-map
and we get this:
Wed Sep 17 18:35:36.537 UTC
% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed' from this session to view the errors
RP/0/RSP1/CPU0:ED_MEX_1(config-pmap-c)#show configuration failed
Wed Sep 17 18:35:49.662 UTC
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
!!% Deny ace not supported in access-list: InPlace Modify Error: Policy TK-MPLS_TG: 'km' detected the 'warning' condition 'Deny ace not supported in access-list'
end
Any kind of help is very appreciated.

That is correct, due to the way the class-matching is implemented in the TCAM, only permit statements in an ACL can be used for QOS class-matching based on ACL.
unfortunately, you'll need to redefine the policy class match in such a way that it takes the permit only.
if you have some traffic that you want to exclude you could do something like this:
access-list PERMIT-ME
1 permit
2 permit
3 permit
access-list DENY-me
!the exclude list
1 permit
2 permit
3 permit
policy-map X
class DENY-ME
<dont do anything> or set something rogue (like qos-group)
class PERMIT-ME
do here what you wanted to do as earlier.
eventhough the permit and deny may be overlapping in terms of match.
only the first class is matched here, DENY-ME.
cheers!
xander

MAC-Adress Filtering vs. Access - Lists

We are using two WLC 4400 Series Controller for our Guest WLAN. They are installed the way Cisco Recommends . One in our LAN and one in the DMZ.
I am looking for a possibility to deny company users the access to this WLAN with their notebooks. The WLAN has direkt internet access and we don't want our notebooks to be compromised...
With MAC-Adress Filterring I can only permit access to a specific Wlan or is there a way to negogiate such a filter to use it for a denial?
Is there a possibility to use access lists for the denial of specific Mac-Adresses to a specific WLAN ?
Anyone an other good Idea how to solve this issue?

Well... MAC-address filter would work, but if you have alot to input, it can be a headache. ACL's I don't think will work, because users will get an ip from the guest network and then how can you know who has what address. Create a username password webauth page. The credentials can be changed each day or week depending.... and give this out to guest users to access the guest network. Now internal user can't access this unless the username password slips out. If you really want to make it tough, use GPO and push out the wireless policy and lock out the feature to add a wireless network.

Cisco ISE and WLC Access-List Design/Scalability

Hi,
I have a scenario whereby wireless clients are authenticated by the ISE and different ACLs are applied to it based on the rules on ISE. The problem I seems to be seeing is due to the limitation on the Cisco WLC which limit only 64 access-list entries. As the setup has only a few SVI/interfaces and multiple different access-lists are applied to the same interface base on the user groups; I was wondering if there may be a scalable design/approach whereby the access-list entries may scale beside creating a vlan for each user group and applying the access-list on the layer 3 interface instead? I have illustrated the setup below for reference:
User group 1 -- Apply ACL 1 --On Vlan 1
User group 2 -- Apply ACL 2 -- On Vlan 1
User group 3 -- Apply ACL 3 -- On Vlan 1
The problem is only seen for wireless users, it is not seen on wired users as the ACLs may be applied successfully without any limitation to the switches.
Any suggestion is appreciated.
Thanks.

Actually, you have limitations on the switch side as well. Lengthy ACLs can deplete the switch's TCAM resources. Take a look at this link:
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/68461-high-cpu-utilization-cat3750.html
The new WLCs that are based on IOS XE and not the old Wireless/Aironet OS will provide the a better experience when it comes to such issues.
Overall, I see three ways to overcome your current issue:
1. Shrink the ACLs by making them less specific
2. Utilize the L3 interfaces on a L3 switch or FW and apply ACLs there
3. Use SGT/SGA
Hope this helps!
Thank you for rating helpful posts!

LMS 4.2 Compliance check extended access-list

Hi,
I would like to check of our router has one specific line in an extended access-list. I have tried to use the 'baseline compliance' to get the output, but can't get the syntax right.
I would like to avoid checking on the line number in the access-list, because this is not the same on all the routers.
I have made a new compliance check like this:
'submode': ip access-list extended 'acl-name'
+deny tcp any any eq smtp
But that is not working, Can some one show me the 'right path'?
Thanks
Soren

Doesnt have any issues on my Lab 4.2.4. following is the Job Work order :
Name:
Archive Mgmt Job Work Order
Summary:
General Info
JobId: 2704
Owner: admin
Description: test_acl
Schedule Type: Immediate
Job Type: Compliance Check
Baseline Template Name: test_acl
Attachment Option: Disabled
Report Type: NAJob Policies
----------------------------------------------------------------------------------------------E-mail Notification: Not Applicable
Job Based Password: DisabledDevice Details
Device
Commands
Sup_2T_6500
ip access-list standard 21
permit host 10.20.30.40
permit host 40.30.20.10
deny any log
10.104.149.180
ip access-list standard 21
permit host 10.20.30.40
permit host 40.30.20.10
deny any log
Check your template, or export it and share, i will try it on my LMS server. also, check the same complaince job on other devices if you have such issues.
-Thanks
Vinod
**Rating Encourages contributors, and its really free. **

Unknown devices appearing in my access list

I have a WPN824 wireless router and in the last two weeks, I've found three devices in the access list that I didn't put there. I first found the three devices last week and deleted them from the list. Tonight, I found them again. All three devices have different MAC address, but use the same device name: "NMADDR." My access list has 12 devices that I added for all the devices I've want to connect
The router is connected to a broadband cable (ComCast) modem.
I manage the router and am the only one with the password. The passsword is a strong 10 character password.
I use Cisco's Network Magic Pro v5.5.9 to manage my home network.
I was wondering if anyone else has run across something like this and can explain how these devices can be "automagically" added to what I thought was a secure router?
Thanks.

May I suggest that this could be either a PDA device, an Apple iTouch or perhaps a WiFi mobile - I had a similiar issue a little time back and this was the ghost in the system.

Static NAT using access-lists?

Hi,
i have an ASA5520 and im having an issue with static nat configuration.
I have an inside host, say 1.1.1.1, that i want to be accessible from the outside as address 2.2.2.2.
This is working fine. The issue is that i have other clients who i would like to access the host using its real physical address of 1.1.1.1.
I have got this working using nat0 as an exemption, but as there will be more clients accessing the physical address than the nat address i would like to flip this logic if possible.
Can i create a nat rule that only matches an access list i.e. 'for clients from network x.x.x.x, use the nat from 2.2.2.2 -> 1.1.1.1' and for everyone else, dont nat?
My Pix cli skills arent the best, but the ASDM suggests that this is possible - on the nat rules page there is a section for the untranslated source to ANY, and if i could change ANY i would but dont see how to...
Thanks,
Des

Des,
You need to create an access-list to be used with the nat 0 statement.
access-list inside_nonat extended permit ip 1.1.1.1 255.255.255.255 2.2.2.2 255.255.255.255
- this tells the pix/asa to NOT perform NAT for traffic going from 1.1.1.1 to 2.2.2.2
then use NAT 0 statement:
nat (inside) 0 access-list inside_nonat
to permit outside users to see inside addresses without NAT, flip this logic.
access-list outside_nonat extended permit ip 2.2.2.2 255.255.255.255 1.1.1.1 255.255.255.255
nat (outside) 0 access-list outside_nonat
you'll also have to permit this traffic through the ACL of the outside interface.
access-list inbound_acl extended permit ip 2.2.2.2 255.255.255.255 1.1.1.1 255.255.255.255
- Brandon

Access list hit counts

Hello Mates,
Am getting a very rare type problem while I implement the aCL on 3850 switch
I do get hit matches when I put a log keyword in the ACL 102
SW#sh ip access-lists
Extended IP access list 102
5 permit tcp 192.168.0.0.0 0.0.255.255 196.189.80.0 0.0.0.15 eq 23 log (28 matches)
But when I remove the log keyword then I don't get any matches.
SW#sh ip access-lists
Extended IP access list 102
5 permit tcp 192.168.0.0.0 0.0.255.255 196.189.80.0 0.0.0.15 eq 23 (no matches )
Please assist.

To understand your issue I think it is helpful to start from the understanding that the hit count is maintained as the access list is processed in software (as is generally the case in layer 3 routers). We get a somewhat different situation in layer 3 switches. If the access list is processed in software (as is necessary when the entry includes the log parameter) then the hit count increments. But when the decision is made in hardware then the right behavior of traffic is achieved but the hit count is not incremented.
HTH
Rick

Virtual telnet/downloadable access lists: acl authorization denied error

Hello,
has someone else experienced the same "issue" as described below ? And can someone (Cisco ?) tell whether this is by design, and if so, what the reasoning is behind this ?
We use virtual telnet for user authentication, when users need to pass traffic through a PIX, and use downloadable access-lists after successful authentication.
When a user authenticates himself, an error message appears in the virtual telnet window: "error: acl authorization denied".
And the PIX log shows:
109005: Authentication succeeded for user 'user1' from <workstation-IP>/2066 to <virtual-telnet-IP>/23 on interface inside
109015: Authorization denied (acl=#ACSACL#-IP-PIX_ACL-421492f3) for user 'user1' from <workstation-IP>/2066 to <virtual-telnet-IP>/23 on interface inside
This error message disappears when we add telnet access for the virtual telnet-IP@ in the downloadable access-list on the Cisco ACS. I could not find any reference to this configuration quirk in any document.
Now, with or without the error, the user can use virtual telnet and everything permitted
in the downloadable acl without any problem (so why post an error message then ?).
thanks

Try to disable authorization and see if this error stops

Pros/Cons of "access-list optimization"

Hello,
We are looking into enabling "access-list optimization" on our FWSM modules and during research we are reading alot pros about this, but are not seeing any cons, so we are wondering if any one out there has ran into any issues or know of possible issues after enabling this feature.
Thanks,
Josh

Welcome to the discussions!
+We currently have Time Capsule running for wireless coverage at one end of our house, and want to extend coverage to the far end. From what I can tell, it seems that we could use either Airport Express or Extreme to extend coverage (correct me if I'm wrong here).+
Either an AirPort Express or AirPort Extreme can "extend a wireless network" providing that it is a newer "n" version of the product.
It sounds like you have a dual band Time Capsule, correct?
Important....if you want to extend both the 2.4 GHz and 5 GHz bands, you would need to look at a dual band AirPort Extreme. The AirPort Express could extend one band, either the 2.4 GHz band or the 5 GHz band, but not both at once.
Unfortunately, it is not possible to extend the Guest network, so this network will not "carry over". "Guests" will have to connect directly to the Time Capsule if you enable the guest network. Their wireless performance will depend on how far and how many obstructions there are between the Time Capsule and their computer.

Access-list MGCP?

On my Cat6500 do I need to do create an access-list to allow MGCP traffic on ports 2427 and 2727 through? I know this sounds dumb but for some reason on my Allied switch MGCP traffic flow fine with no access list and it doesn't on the Cat6500.
Thanks!

u dont unless u have FWSM, or any kind of ACLs, or maybe VLANs issue, or ip routing, vlan routing
check those issues
Rate if helpful

Help with an access list please

Hi guys, i have an access list applied inbound to an interface on a router at the edge of our LAN.Our LAN subnet is 10.10.x.x and the incoming subnet is 10.13.x.x both with a 16 bit mask. The ACL is applied inbound to the interface that the the 10.13.x.x subnet come in on. I want to only allow them to go to our internal webserver to run a corporate web app, resolve dns for this web server with our dns servers, and have full access to a server on the other side of our WAN for another 32 bit app they are running. Here is my ACL:(you will notice i have also configured a single ip full access in for us to use when we are on site)
access-list 101 permit ip 10.10.0.0 0.0.255.255 any
access-list 101 permit ip host 10.13.1.254 any
access-list 101 permit udp 10.13.0.0 0.0.255.255 host 10.10.10.1 eq domain
access-list 101 permit udp 10.13.0.0 0.0.255.255 host 10.10.10.2 eq domain
access-list 101 permit tcp 10.13.0.0 0.0.255.255 host 10.10.10.2 eq domain
access-list 101 permit tcp 10.13.0.0 0.0.255.255 host 10.10.10.1 eq domain
access-list 101 permit ip 10.13.0.0 0.0.255.255 host 192.168.9.1
access-list 101 permit tcp 10.13.0.0 0.0.255.255 host 10.10.10.24 eq www
access-list 101 deny ip 10.13.0.0 0.0.255.255 10.0.0.0 0.255.255.255
access-list 101 deny ip 10.13.0.0 0.0.255.255 172.16.100.0 0.0.0.255
access-list 101 deny ip any any
From the 10.13.x.x network this works like a charm but here is the key: i want to be able to remote admin their machines but cant. Even though the ACL is applied inbound only i cant get to their subnet, even with the first permit statement i still cant get to their subnet. I am assuming its allowing me in but the problem is lying with the return traffic. Is their a way for me to deny them access as in the list but for me to remote their subnet?
Any help you could offer would be appreciated.

I agree with you that the first line in the access list is incorrect. Coming in that interface the source address should never be 10.10.0.0. But if he follows your first suggestion then any IP packet from 10.13.anything to anything will be permitted and none of the other statements in the access list will have any effect.
And I have a serious issue with what he appears to suggest which is that he will take his laptop (with a 10.10.x.x address), connect it into a remote subnet, and expect it to work. Unless he has IP mobility configured, he may be able to send packets out, but responses to 10.10.x.x will be sent to the 10.10.0.0 subnet and will not get to his laptop. He needs to rething this logic.
I do agree with your second suggestion that:
access-list 101 permit tcp 10.13.0.0 0.0.255.255 eq 5900 10.10.0.0 0.0.255.255
should allow the remote administration to work (assuming that 5900 is the correct port and assuming that it uses tcp not udp).
HTH
Rick

With Timed Access List on, Guest users cannot access Guest network.

I have a ABS with 7.5 version. In the Timed Access window i have default set to "no access". Then, all the computers that are allowed access to the main network are on the list. Then i have the main network hidden. My guest network is broadcasting but when a user tries to connect to it, they get a "Unable to connect". If I change the default access in Timed Access to "Everyday", users are then able to connect to the Guest network again.
Obviously, this is a bug. I don't want people accessing the main network that aren't on the timed access list. However, I still want guest users to access the Guest Network.
It looks to me that the Timed Access window is controlling the restriction of the Guest and Main network, when it should only be controlling the Main only.
Hopefully, apple has noted this issue and will be fixed on the new update. If other people are experiencing this problem, Please let me know.
-Ghost

Apple just updated the airport to 7.5.1. But there is still a problem with the the guest network not allowing access. If the "Unlimited" is set to "No Access" in the access list it prevents anybody from accessing the guest network. It should only deny your Main wireless Network.
In other words, the Access List is controlling the access for both wireless networks(Guest and Main network)
Either apple needs to create two Access Lists, One for Main network, and One for guest network. Or just have to option to choose which Network you want to restrict leaving the second one open for all.
-Ghost

Access list issues

Similar Messages

Maybe you are looking for