When I create access lists and assign them to a policy-class, they have no effect when applied to traffic that is passing through the unit. I can manipulate any traffic that is traveling to the unit; NAT configurations work as well. However, when I use the the 'allow list <access list>' command, it does absolutely nothing for me. This example configuration should block all traffic that is passing through inbound on eth 0/1, but it doesn't. Any suggestions on what I am doing wrong?
ip access-list standard Self-acl
permit any
ip access-list standard DenyAll-acl
deny any
ip policy-class Public
allow list Self-acl self
allow list DenyAll-acl
interface eth 0/1
ip access-policy Public
I contacted Adtran support and Wil helped clarify things for me. I wanted to post the results here in case anyone else finds themselves confused by the same thing. In the Cisco world, a 'deny any' statement will block all traffic. However, in the Adtran world, when you use a 'allow list' with an access list that has a 'deny any' statement, you actually aren't doing anything at all, neither blocking nor permitting. Also, the reason that nothing was getting blocked from getting through the WAN interface of the router was due to stateful inspection by the firewall. Any traffic that is initiated from the private interface will be allowed back in regardless of the rules in my policy-class. Here is the super helpful explanation from Wil regarding Access Control Policies:
The Access Control Lists are used as selectors to match traffic (either permit or deny). Then, the Access Control Policy of that interface is where the action is performed (either allow or discard). If traffic matches the criteria of the deny statement then it will not perform the action of the ACP and instead will move on to the next rule. An ACL with a deny statement does not block traffic. Instead, the traffic needs to match an ACL with a permit statement, it will then perform the action of the ACP, either allowing or discarding the traffic. If it matches none of the rules that have been created then it will be blocked by the implicit discard that is automatically applied to all ACPs.
For example, if you look at the sample config you sent me, if a computer on the private side begins to ping google then the traffic would enter the box on the vlan 1 interface.The access-policy "Private" and begins to examine the traffic in a top down fashion. The first rule is an allow for the ACL "self" for all traffic from the source of any to the destination of any with the "self" statement meaning the ip address of the box. This rule is allowing any ip traffic from the private side, destined to the box ip address through the firewall.
The second rule "nat source list wizard-ics interface eth 0/1 overload" is going to perform a NAT on the source address of any traffic that matches the ACL "wizard-ics" which is "permit any" This means all traffic initiated from the private side, will match this ACL and because it is a permit, it will then perform the action of the ACP (in this case a NAT).
If we look at the policy class "Public" we see the rule "allow list DenyAll-acl" this will allow any traffic that matches the ACL, "DenyAll-acl" However, the "Deny-All-acl" is a deny any which means that any traffic that matches this rule (which is everything) will skip this ACP and move on to the next rule. The first rule of the Public policy class isn't performing any action. Instead the traffic is moving on to the next rule after "allow list DenyAll-acl" which in our case is the implicit Discard that is there by default. Any traffic that is initiated from the internet to your public interface is being blocked by that implicit discard automatically applied on the bottom of all ACPs.
Steve,
There is an implicit 'discard' at the end of your Public Policy so you can just make your Public Policy:
ip policy-class Public
allow list Self-acl self
Otherwise you would want to use a 'discard' instead of an 'allow' in the 'Public' policy and permit all traffic in the ACL 'DenyAll-acl':
ip access-list standard Self-acl
permit any
ip access-list standard DenyAll-acl
permit any
ip policy-class Public
allow list Self-acl self
discard list DenyAll-acl
interface eth 0/1
ip access-policy Public
Please let me know if you have any questions.
-Donna
Thanks Donna,
I actually have already tried those things, but they didn't work for me. It still allowed all traffic through the unit. I have updated the Netvanta 3120 to the latest firmware and still get the same results. My goal isn't actually to block all traffic like I have in my example, I am just trying to figure out how to apply an access list to an interface so that I can allow only connections from certain IP ranges. My actual configuration looks more like this:
interface eth 0/1
ip address dhcp
ip access-policy Public
no shutdown
interface vlan 1
ip address 192.168.0.1 255.255.255.0
ip access-policy Private
no shutdown
ip access-list standard DenyAll-acl
deny any
ip access-list extended LimitAccess-acl
permit ip **** 0.0.3.255 any
permit ip **** 0.0.3.255 any
permit ip **** 0.0.3.255 any
deny ip any any
ip access-list standard NAT-acl
permit any
ip policy-class Private
nat source list NAT-acl interface eth 0/1 overload
ip policy-class Public
allow list DenyAll-acl self
allow list LimitAccess-acl
I appreciate any help that you can give me. Thanks again.
- Steve
Steve,
If your goal is to only allow traffic specified in the ACL ‘LimitAccess-acl’ and block all other traffic to the 3120, then remove ‘allow list DenyAll-acl self’ from the Public Policy. All traffic to the 3120 will be blocked except for the traffic specified in ‘LimitAccess-acl’.
ip policy-class Public
allow list LimitAccess-acl
If you need additional assistance please let me know.
-Donna
So, here is the problem that I am having. I have some 20 variants of the above config deployed as internet routers. I didn't set them up that way. Rather, the phone company sends them to us that way. They have an access list that they designed to allow all traffic from their IP ranges. However, if that access list was actually working, the phones would be the only things working as all other traffic is getting blocked. That would be bad. Why isn't the traffic getting blocked, though? Is there a bug in the Netvanta 3120 that ignores all 'allow list *' commands if it isn't followed by another statement like 'self'? That is why my original example blocked all traffic. I have no interest in blocking all traffic, I am just trying to show that the command doesn't work on these routers. I figured at first that I had the syntax wrong. However, now that I see your syntax is identical to my own, I am thinking it has to be a bug in the firmware. Oddly enough, I have updated to the latest firmware and still get the same issue. Would you like me to create a simple configuration of a router to demonstrate the problem so that you can load that configuration on a router of your own? Thanks for your help.
- Steve
Steve,
I would recommend you open a support case to look at your issue further.
-Donna
I contacted Adtran support and Wil helped clarify things for me. I wanted to post the results here in case anyone else finds themselves confused by the same thing. In the Cisco world, a 'deny any' statement will block all traffic. However, in the Adtran world, when you use a 'allow list' with an access list that has a 'deny any' statement, you actually aren't doing anything at all, neither blocking nor permitting. Also, the reason that nothing was getting blocked from getting through the WAN interface of the router was due to stateful inspection by the firewall. Any traffic that is initiated from the private interface will be allowed back in regardless of the rules in my policy-class. Here is the super helpful explanation from Wil regarding Access Control Policies:
The Access Control Lists are used as selectors to match traffic (either permit or deny). Then, the Access Control Policy of that interface is where the action is performed (either allow or discard). If traffic matches the criteria of the deny statement then it will not perform the action of the ACP and instead will move on to the next rule. An ACL with a deny statement does not block traffic. Instead, the traffic needs to match an ACL with a permit statement, it will then perform the action of the ACP, either allowing or discarding the traffic. If it matches none of the rules that have been created then it will be blocked by the implicit discard that is automatically applied to all ACPs.
For example, if you look at the sample config you sent me, if a computer on the private side begins to ping google then the traffic would enter the box on the vlan 1 interface.The access-policy "Private" and begins to examine the traffic in a top down fashion. The first rule is an allow for the ACL "self" for all traffic from the source of any to the destination of any with the "self" statement meaning the ip address of the box. This rule is allowing any ip traffic from the private side, destined to the box ip address through the firewall.
The second rule "nat source list wizard-ics interface eth 0/1 overload" is going to perform a NAT on the source address of any traffic that matches the ACL "wizard-ics" which is "permit any" This means all traffic initiated from the private side, will match this ACL and because it is a permit, it will then perform the action of the ACP (in this case a NAT).
If we look at the policy class "Public" we see the rule "allow list DenyAll-acl" this will allow any traffic that matches the ACL, "DenyAll-acl" However, the "Deny-All-acl" is a deny any which means that any traffic that matches this rule (which is everything) will skip this ACP and move on to the next rule. The first rule of the Public policy class isn't performing any action. Instead the traffic is moving on to the next rule after "allow list DenyAll-acl" which in our case is the implicit Discard that is there by default. Any traffic that is initiated from the internet to your public interface is being blocked by that implicit discard automatically applied on the bottom of all ACPs.