07-24-2016 07:37 AM - edited 03-08-2019 06:45 AM
When using NAT overload what, if any, is the difference between the following two access-list entries? I've seen it documented both ways and both appear to work the same way. Is there any situation where you would want to use one over the other?
access-list 100 permit ip 0.0.0.0 255.255.255.255 any
access-list 100 permit ip any any
Also, I've read in documentation that using the any any access list entry for NAT is discouraged. Is that strictly for security or are there other reasons; processing overhead for instance? Of corse this question would only apply in situations where all attached subnets should use NAT.
Thanks
Solved! Go to Solution.
07-24-2016 12:52 PM
Hi Chris,
Those two ACL lines are entirely equivalent. The word any is simply a shorthand for 0.0.0.0 255.255.255.255 and in fact, whenever you enter 0.0.0.0 255.255.255.255 in your ACL, IOS will automatically replace it with any:
Router(config)# do show access-lists
Router(config)# access-list 100 permit ip 0.0.0.0 255.255.255.255 any
Router(config)#
Router(config)# do show access-lists
Extended IP access list 100
10 permit ip any any
Router(config)# do show run | i access-list
access-list 100 permit ip any any
Router(config)#
Also, I've read in documentation that using the any any access list entry for NAT is discouraged.
Yes, that is true. Besides the obvious functional and security implications of blindly allowing any traffic to be translated by NAT/PAT, you really should not allow your NAT/PAT to apply to packets that have already been translated. I may be in error but I faintly recall playing with NAT on a fairly old IOS (12.3 at most, probably 12.2) where I used an permit ip any any kind of ACL, and I saw that the IOS generated multiple translation entries for a single packet, as if it was translated multiple times. Since then, I was not able to reproduce the behavior, so there could have been something else in play, but that was the first time I realized that it makes no sense to have an ACL that allows the translated traffic to be translated again.
Of corse this question would only apply in situations where all attached subnets should use NAT.
Just to be sure you are aware of it: NAT can apply to traffic sourced from any network, not just a directly connected network. You can have a large topology over several routers with multiple end networks, and still have a single router do the NAT/PAT for this entire topology. It would require configuring an ACL that covers all internal networks, but it is a common deployment scenario.
Feel welcome to ask further!
Best regards,
Peter
07-24-2016 12:52 PM
Hi Chris,
Those two ACL lines are entirely equivalent. The word any is simply a shorthand for 0.0.0.0 255.255.255.255 and in fact, whenever you enter 0.0.0.0 255.255.255.255 in your ACL, IOS will automatically replace it with any:
Router(config)# do show access-lists
Router(config)# access-list 100 permit ip 0.0.0.0 255.255.255.255 any
Router(config)#
Router(config)# do show access-lists
Extended IP access list 100
10 permit ip any any
Router(config)# do show run | i access-list
access-list 100 permit ip any any
Router(config)#
Also, I've read in documentation that using the any any access list entry for NAT is discouraged.
Yes, that is true. Besides the obvious functional and security implications of blindly allowing any traffic to be translated by NAT/PAT, you really should not allow your NAT/PAT to apply to packets that have already been translated. I may be in error but I faintly recall playing with NAT on a fairly old IOS (12.3 at most, probably 12.2) where I used an permit ip any any kind of ACL, and I saw that the IOS generated multiple translation entries for a single packet, as if it was translated multiple times. Since then, I was not able to reproduce the behavior, so there could have been something else in play, but that was the first time I realized that it makes no sense to have an ACL that allows the translated traffic to be translated again.
Of corse this question would only apply in situations where all attached subnets should use NAT.
Just to be sure you are aware of it: NAT can apply to traffic sourced from any network, not just a directly connected network. You can have a large topology over several routers with multiple end networks, and still have a single router do the NAT/PAT for this entire topology. It would require configuring an ACL that covers all internal networks, but it is a common deployment scenario.
Feel welcome to ask further!
Best regards,
Peter
07-24-2016 07:16 PM
Thanks for the detailed explanation. I figured it was the same, but I'm still in the beginning phase of learning so I wanted to make sure that my assumption was correct. I haven't really gotten in depth with NAT/PAT yet. I understand the basic principle of how it works as I have been in IT for a long time (just now starting to really learn Cisco) as a Windows Server admin, but the details are still a little fuzzy.
On your last point, I have recently been made aware of that as I have been experimenting in my home lab with static routing and RIP. All of the scenarios I have setup thus far have used NAT to provide the lab access to the real internet.
I do have one other, unrelated question that I just thought of in regard to my home lab...
I have 6 routers in my lab including (2) 2610XM routers and a 2811. The 2610s each have 2 WIC1 DSU-T1 cards and the 2811 has 3 WIC1 DSU-T1-V2 cards. I can create point-to-point serial links between them with no problem, but if I try to make one of the 2811's cards the DCE by issuing the clock rate command, I get an error saying that the command only applies to DCE interfaces. Is this a limitation with the V2 version of the WICs or is there something else at play? It hasn't caused me a problem other than a minor annoyance because if I am using a point-to-point link I have to make sure I plan the topology so that the 2610XMs are the DCE.
Thanks for your assistance!
07-25-2016 06:38 AM
Hi Chris,
You are very much welcome.
if I try to make one of the 2811's cards the DCE by issuing the clock rate command, I get an error saying that the command only applies to DCE interfaces. Is this a limitation with the V2 version of the WICs or is there something else at play?
Cisco serial interfaces can act both as DCE and DTE interfaces, and the particular mode of operation in fact depends on the serial cable that is connected to them. The cable (its internal wiring) tells the card whether it should operate as a DCE or a DTE endpoint. So if the router believes you have a DTE cable connected to it then it will refuse the clock rate command. If the both connectors of the particular serial cable are identical, you could try to reverse the cable (exchange both ends between the same routers) and test the clock rate again - now, the 2600XM router should complain and the 2811 should be happy.
You can always ask the router about the type of cable it believes it is connected to by issuing the show controllers serial x/y/z command. The output is extremely technical but somewhere at the very top of the output, check for an indication of either a DCE or a DTE cable along with its type (V.35, X.21, RS-449, ...).
It should be noted that in typical real world scenarios, the router would be a DTE device, and so would use a DTE cable that would connect to a modem on the other end, and the modem would be doing the DCE job. For lab purposes, modems are ignored, and we're using back-to-back serial cables that make one router act as DTE, and the other router as a DCE device.
Best regards,
Peter
07-26-2016 04:16 AM
I appreciate the info.
I ran the show controllers command on both routers and can not find an indication of DCE or DTE and cable type in the output.
The output of the 2610XM which is the DCE bellow. Note the serial link is up/up and I can ping between them. The same command on the 2811 gives me a similar output with no indication that I can find of DCE or DTE.
07-26-2016 04:39 AM
Chris,
My apologies, I have mistaken your WIC cards for serial cards; in reality, your WIC modules are T1 modules using ISDN PRI T1 framing.
I actually doubt that on these modules, the clock rate command makes any sense whatsoever, because T1 has a fixed physical parameter set. When you actually configure the clock rate on either side of the link, does the command appear on the interface when you check the show running-config output?
Best regards,
Peter
07-26-2016 07:36 AM
No it does not.
Your explanation also makes sense to me because even though I set the clock rate at 64000 the interface can still transfer data at ~T1 speeds 1.5Mbps so it seems that the clock rate command, although no error is given, has no effect on the interfaces.
I learned how to configure back to back serial links between routers a while ago from a source I don't remember. I think maybe that source was using routers with serial cards instead of the WICs in it's examples and I just didn't know enough to establish the difference.
So all this still begs the question of why the WICs in the 2811 can't be the DCE?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide