10-11-2010 02:34 AM - edited 03-04-2019 10:03 AM
I'm having difficulty applying an ACL to a Dialer Interface on an 861W, where all traffic is being denied and appears to be a NAT issue, but not sure how to resolve it.
The 861 is configured with a Dialer Interface which essentially utilises the FastEthernet4 connection, which is in turn connected to an ADSL Modem operating in Full Bridge Mode.
Whilst NAT and traffic flow etc appears to be operating correctly without an ACL, when adding an inbound one to the Dialer Interface(Which is configured as an Outside Interface), all traffic seems to be denied. When inspecting the logs the source and destination addresses/ports appear to be reversed?
e.g. External_To_Internal_ACL denied tcp 69.63.180.47(80) -> 222.154.224.110(3201)
Relevant configuration parameters are
interface FastEthernet4
pppoe-client dial-pool-number 1
interface Vlan1
ip address 192.168.50.7 255.255.255.0
ip access-group Internal_To_External_ACL in
ip nat inside
ip policy route-map NAT_RM
interface Dialer1
ip inspect Extnl-Intnl-CBAC in
ip nat outside
route-map NAT_RM permit 10
match ip address NAT_RM_ACL
set ip next-hop 172.16.255.2
Interface Loopback0
ip address 172.16.255.1 255.255.255.0
ip access-list extended Internal_To_External_ACL
permit tcp any any established
ip inspect name Extnl-Intnl-CBAC tcpAdding an ip inspect Extnl-Intnl-CBAC Out to the dialer interface seems to resolve this issue to a degree(But not for all traffic..)
Any help figuring out how to get an ACL applied to the External Interface correctly would be appreciated as this is a bit over my head technically..
10-11-2010 03:02 AM
Are you trying to block all inbound traffic towards the dialer interface? So your router will only be allowing outbound traffic?
If the above statement is correct, here is what you would need to configure:
interface Vlan1
ip inspect Extnl-Intnl-CBAC in
access-list 105 deny ip any any
interface Dialer1
ip access-group 105 in
You would need to remove the existing ACL applied on VLAN 1, and also remove existing ip inspect applied on Dialer1 interface.
Hope that helps.
10-11-2010 03:22 AM
Thanks for the suggestion Jenifer.
Whilst this does provide something that functions, we were already aware that adding the CBAC to the VLAN Interface to a degree resolves the way the ACL's behave on this interface. The plan is to limit Inbound traffic
The reason we have been trying to move away from this VLAN/CBAC configuration is that we have found the 861 just didn't appear to handle inspecting multiple CBAC's. Seemed to cope OK with UDP and TCP but with HTTP and HTTPS it had a serious degradation to customers web browsing performance.
Ar e you aware of any other way to achieve this without utilising CBAC on this VLAN interface? I cannot help but think we should be able to get traffic inspected and ACL'd without the use of these, but I have limited experience in this space.
10-11-2010 04:11 AM
If you find that HTTP and HTTPS performance are degraded using CBAC, then you can remove the inspection for HTTP and HTTPS, and just have the generic inspection which would provide more security than just a pure ACL without CBAC.
You can just configure the following CBAC list:
ip inspect name Extnl-Intnl-CBAC tcp
ip inspect name Extnl-Intnl-CBAC udp
ip inspect name Extnl-Intnl-CBAC time
ip inspect name Extnl-Intnl-CBAC ntp
ip inspect name Extnl-Intnl-CBAC ftp
ip inspect name Extnl-Intnl-CBAC dns
ip inspect name Extnl-Intnl-CBAC icmp
which will still provide better security than just ACL.
10-16-2010 06:24 PM
Sorry for the delay have been "Trying" some options around using CBAC on various interfaces to resolve some of these issues.
We have ended up utilising an option of only CBAC inspecting outbound traffic on the external Interface, which works and there are no apparant issues with traffic flow, but we are still getting some traffic that appears to not be properly tracked through the router/firewall correctly... At the moment the External Interface Inbound ACL is picking this up... e.g.
External_To_Internal_ACL denied tcp 222.186.34.107(80) -> 222.154.224.227(62842)
These are the CBAC rules that are applied at the moment..
ip inspect name EXTNL_CBAC tcp
ip inspect name EXTNL_CBAC https
ip inspect name EXTNL_CBAC udp
ip inspect name EXTNL_CBAC time
ip inspect name EXTNL_CBAC ntp
ip inspect name EXTNL_CBAC ftp
ip inspect name EXTNL_CBAC dns
ip inspect name EXTNL_CBAC icmp
I suspect what happens is that if the CBAC can track the traffic within it's "Capabilities", then the router and ACL's etc will operate as expected. If not then your going to have the issues we are experiencing(Although outside what appears to be bogus log entries these don't impact things working..)
The issue we have is that we check these ACL denied logs and having to take the approach of they could be real , they could be bogus, makes for a less than professional approach to firewall management.
We have also had issues with the CBAC rules "Breaking" legitimate traffic, which is what I suspect we have not included HTTP in the above list
Is there a Cisco best practise document for using CBAC in a router/firewall and specifically in relation to perhaps both ACL's and NAT? It seems to me lots of people have issues around this area, that Cisco could help by publishing a document like this(If they haven't already..)
Cheers again for any help that can be provided...
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