Cisco1921 Cellular 0/0/0 Not Filtering ACL (out bound)

michael.lorincz · ‎10-01-2014

Hello,

In the past on a 881 I've been able to NAT traffic out the Cellular 0/0/0 interface with an ACL on Cell0/0/0 permitting only NAT'd traffic and denying everything else. This was done to prevent traffic leaving cell0/0/0 with a source address other than the ISP assigned WAN IP. For some reason on the 1921 the access list is not being utilized and non-nat'd traffic is also leaving the interface which causes the link to flap since the ISP detects source address violations. Any idea on what would be causing this?

I even stripped the config down to the following but the problem persists, any advice?

ip route 0.0.0.0 0.0.0.0 Cellular0/0/0 5

!
interface Loopback0
description Management Interface (do not shut)
ip address 10.224.0.165 255.255.255.255
ip nat inside
ip virtual-reassembly in

!

ip access-list extended TEST-CELL-ACL

deny ip any any

deny icmp any any

!

interface Cellular0/0/0

ip address negotiated

ip access-group TEST-CELL-ACL out

no ip unreachables

ip nat outside

ip virtual-reassembly in

zone-member security OUTSIDE

encapsulation slip

load-interval 30

dialer in-band

dialer idle-timeout 0

dialer string ltescript

dialer watch-group 1

async mode interactive

end

-------------------------------------------------------------

SG-142-1921#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 104/110/116 ms

SG-142-1921#ping 8.8.8.8 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.224.0.165

.....
Success rate is 0 percent (0/5)
000083: *Oct 1 20:16:48.115 UTC: %LINK-5-CHANGED: Interface Cellular0/0/0, changed state to reset
000084: *Oct 1 20:16:49.115 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/0/0, changed state to down...
000085: *Oct 1 20:16:53.115 UTC: %LINK-3-UPDOWN: Interface Cellular0/0/0, changed state to down.
Success rate is 0 percent (0/5)

SG-142-1921#sh ip access-lists TEST-CELL-ACL
Extended IP access list TEST-CELL-ACL
10 deny ip any any
20 deny icmp any any
SG-142-1921#

Richard Burts · ‎10-02-2014

The issue here is that an access list applied outbound on an interface does not filter traffic that is generated by the router itself. Your access list will prevent any transit traffic (traffic sent to the router to be forwarded by the router) but will not prevent traffic generated by the router.

You have not shown us how address translation is being done. If the ISP is detecting source address violations then it suggests that there is a flaw in your address translation logic.

HTH

Rick

HTH

Rick

michael.lorincz · ‎10-02-2014

Hi Richard,

Thank you very much for your response. Very helpful indeed but I'm still unsure on how to resolve. Please see below for existing NAT statement and associated ACL as well as the ACL we were using on the cellular interface (the permit statement matches the static IP assigned by the provider). When I would ping a global address not listed in the POS ACL sourced by Lo0 the outbound ACL would not filter it and the link would flap.

ip nat inside source list POS interface Cellular0/0/0 overload

ip access-list extended POS
permit ip 10.0.45.0 0.0.0.255 4.79.143.0 0.0.0.255
permit ip 10.0.45.0 0.0.0.255 208.80.28.0 0.0.0.255
permit ip 10.0.45.0 0.0.0.255 12.71.112.0 0.0.0.255
permit ip 10.0.45.0 0.0.0.255 72.167.18.0 0.0.0.255
permit ip any 12.9.235.0 0.0.0.255
permit ip any 198.140.216.0 0.0.0.255
permit ip any 63.91.129.0 0.0.0.255
permit ip 10.0.45.0 0.0.0.255 host 63.241.207.105
permit ip 10.0.45.0 0.0.0.255 host 66.43.144.238
permit ip 10.0.45.0 0.0.0.255 host 108.241.204.225
permit ip 10.0.45.0 0.0.0.255 host 209.36.33.43
permit ip 10.0.45.0 0.0.0.255 host 12.132.59.7
permit ip 10.0.45.0 0.0.0.255 host 68.178.177.2
permit ip any host 207.67.74.163
permit ip any host 66.196.48.162
permit ip any host 98.124.198.1
permit ip any host 72.32.118.67
permit ip any host 137.200.4.16
permit ip any host 199.173.225.5
permit ip any host 119.173.231.136
permit ip any host 199.173.231.136
permit ip any host 208.31.22.249
permit ip host 64.183.24.194 any
permit icmp 10.0.45.0 0.0.0.255 host 8.8.8.8
permit icmp host 10.224.0.165 host 8.8.8.8

!

!
interface Cellular0/0/0
ip address negotiated
ip access-group FILTER-NON-NAT out
no ip unreachables
ip nat outside
ip virtual-reassembly in
zone-member security OUTSIDE
encapsulation slip
load-interval 30
dialer in-band
dialer idle-timeout 0
dialer string ltescript
dialer watch-group 1
async mode interactive
end
ip access-list extended FILTER-NON-NAT
permit ip host 166.139.240.166 any

!

Richard Burts · ‎10-02-2014

This is interesting and I have couple of comments.

- The ACL applied outbound on the cellular interface should be pretty effective in blocking transit traffic that is not translated. If the ISP is seeing source address violations then it suggests that the traffic is probably generated by the router itself rather than being transit traffic.

- I do not know how many interfaces are on the router and how many subnets it is processing for and that might have some impact on how you do the address translation and manage traffic. The only interface you have shown so far is the loopback. And the ACL for translation only permits ICMP traffic from the loopback to a specific host. I would think that you would want to permit lots more types of traffic from the loopback. In fact I do not understand why you do not just permit anything from the loopback.

- That leads me to the observation that the ACL for address translation looks a lot like the kind of access list you would use to manage traffic on an interface. I would suggest that the ACL for address translation should be more simple and more broad. I do not see why any traffic sourced from any router interface would not be translated. And frankly I would think that any transit traffic coming through an interface probably ought to be translated. If you want to control what traffic can go where then do it with an ACL on the interfaces.

Perhaps another way of looking at it is that you are translating traffic to avoid source address violations and the accompanying interface resets. So I would be motivated to be sure that anything going out the cellular interface is translated. If you want to control what traffic is allowed to go out then not translating it and letting the ISP discard it is a counter productive approach in my opinion. I think it would be better to filter and control traffic with ACL on interfaces and then translate everything that survives your interface ACL.

And you could certainly change your FILTER-NON-NAT access list from permit any destination and put your logic for selective destinations into this exit interface filter.

HTH

Rick

HTH

Rick

michael.lorincz · ‎10-02-2014

Thanks for setting me straight, Richard. I think you're spot on with your recommendation to filter at the local interfaces. The customer has a very locked down network and only permits a handful of hosts to access specific internet IPs (per the POS ACL). Someone suggested we use NAT to filter out the hosts but I believe your method is better.

I made some revisions (shown below). It appears to be sound but I'm experiencing some filtering issues. To further compliate matters we are running HSRP between the primary router and a secondary router.

Tested by connecting laptop with IP 10.10.45.20 to primary 1921 router, interface is in VLAN 10. From the laptop I'm unable to ping 8.8.8.8 and I'm unable to ping 10.10.45.252 (secondary router's IP). Both of which should work based on the POS ACL applied to interface VLAN10.