ACL not working with NAT

[Jonasye]

I'm studying on Cisco packet tracking, I just found one strange thing. I attached the network map and configuration below.

1> I created NAT for 10.2.0.0/16 and 10.3.0.0/16 to access the server0.

2> Created ACL for 10.2.100.0 0.0.0.255 to not allow access server www

     Created ACL for 10.3.100.0 0.0.0.255 to not allow access server ftp

Now the problem comes, the PC0 still can access the server www, same as PC2 can access FTP.

But if I deleve the nat command line, the ACL works.

I'm confused, the ACL should always work before NAT, it looks like the NAT bypassed the ACL with its outbound IP address without filtered. how does this happen???

!
interface FastEthernet0/0
 ip address 10.1.50.1 255.255.0.0
 ip access-group 110 out
 ip nat outside
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.2.1.1 255.255.0.0
 ip nat inside
 duplex auto
 speed auto
!
interface FastEthernet0/1.3
 encapsulation dot1Q 3
 ip address 10.3.1.1 255.255.0.0
 ip nat inside
!
interface Vlan1
 no ip address
 shutdown
!
ip nat pool internet 10.1.50.50 10.1.50.50 netmask 255.255.0.0
ip nat inside source list 2 pool internet overload
ip classless
!
ip flow-export version 9
!
!
access-list 2 permit 10.2.0.0 0.0.255.255
access-list 2 permit 10.3.0.0 0.0.255.255
access-list 110 deny tcp 10.2.100.0 0.0.0.255 host 10.1.1.1 eq www
access-list 110 deny tcp 10.3.100.0 0.0.0.255 host 10.1.1.1 eq ftp
access-list 110 permit ip any any
!
!
!

[Georg Pauwen]

Hello,

output access lists are applied AFTER Nat, input access lists before. Apply the access list inbound.

[Jonasye]

Hi, Georg, do you mean change ip access-group 110 out to ip access-group 110 in under the same port?

[Georg Pauwen]

Hello,

exactly.

[paul driver]

Hello

Your nat only refers to access-list 2 so when you say you deleted a nat command what do you mean?  Also by in mind when a network translation occurs that translation is kept in a the network translation table for a period of time before it expires unless that is you manually clear it. 

[Jonasye]

H, Paul, if only I delete the ip nat inside and ip nat outside, the ACL then work, it confused me.

[Tyson Joachims · Accepted solution]

The reason the ACL did not block Web & FTP traffic with NAT enabled was because your traffic destined for the server has its source IP address translated to that of the NAT pool before being evaluated by the ACL 110. The traffic did not match the deny statements. Applying ACL 110 in the inbound direction on interface FastEthernet0/0; however, will not have the desired outcome for 2 reasons (I tested it in Packet Tracer just to be sure):

1. The ACL will be evaluating traffic incoming on FastEthernet0/0 which means your source and destination networks are reversed for that direction of traffic flow. Essentially the web & FTP request traffic from 10.2.100.0/24 & 10.3.100.0/24 will reach the server and you are trying to block the returning response traffic from the server if you are placing an ACL on FastEthernet0/0 in the inbound direction.

2. The ACL is evaluated prior to the NAT translation in that direction so the Web/FTP server will be sending traffic destined for 10.1.50.50 which will not match your deny statements which are looking for 10.2.100.0/24 or 10.3.100.0/24.

If you want the NAT to work as well as block Web & FTP from the respective networks, my recommendation is to create two access lists and apply them to the sub-interfaces in the inbound direction like so:

access-list 112 deny tcp 10.2.100.0 0.0.0.255 host 10.1.1.1 eq www
access-list 112 permit ip any any
!
access-list 113 deny tcp 10.3.100.0 0.0.0.255 host 10.1.1.1 eq ftp
access-list 113 permit ip any any
!
interface FastEthernet0/1
 ip access-group 112 in
!
interface FastEthernet0/1.3
 ip access-group 113 in

---Please consider rating response as Helpful if you found it so---

[Jonasye]

Thanks for your answer, I've tested it works, does that means the NAT can bypass the ACL if put on a outbound port?

So in the real world, does this mean we always should apply ip access-group XXX near the source using IN instead put near the destination port using OUT? Because NAT translated the source IP

[Tyson Joachims]

NAT is changing the source IP address of the outbound traffic so the ACL will not match the desired traffic. It is best practice to place an extended access list as close to the source as possible (I've seen this saying a lot in various locations).

You can most definitely use an ACL outbound on your Internet interface. I often times put an ACL that denies all RFC-1918 addresses so that any networks that don't get translated to a public address (such as my Management and Voice networks), they get denied before being sent to my ISP. All translated traffic is allowed because it won't match my ACL.

Why would I do this? ISPs are not supposed to route RFC-1918 addresses so they are supposed to drop those packets if they ever receive them from a customer. If you're network is sending any traffic to them with a source RFC-1918 address, it's not the end of the world but I like to stop it before it leaves my network.

interface FastEthernet0/0
 ip address 1.1.1.1 255.255.255.240
 ip access-group 10 out
 ip nat outside
!
interface FastEthernet0/1
 ip address 10.2.1.1 255.255.0.0
 ip nat inside
!
interface FastEthernet0/1.3
 encapsulation dot1Q3
 ip addres 10.3.1.1 255.255.0.0
 ip nat inside
!
ip nat inside source list 2 interface FastEthernet0/0 overload
!
access-list 2 permit 10.2.0.0 0.0.255.255
access-list 10 deny 10.0.0.0 0.255.255.255
access-list 10 deny 172.16.0.0 0.15.255.255
access-list 10 deny 192.168.0.0 0.0.255.255
access-list 10 permit any

I've modified your config so that FastEthernet0/0 now has an address that is not an RFC-1918 address. The ACL 2 which is used for your NAT does not specify 10.3.0.0/16 so that subnet will not be translated when trying to go to the server. Since it won't be translated, the new ACL 10 will match it with a deny statement and drop the packets.

[paul driver]

Hello @Tyson Joachims  

my understanding this doesn’t need to done - the most simplistic solution would be just to amend the existing acl2 to deny those hosts not to be natted as such the acl110 will be read by the rtr meaning no re-addressing is required 

[Tyson Joachims]

@paul driver  That doesn't seem to satisfy his original requirements. He wants the traffic from 10.2.100.0/24 & 10.3.100.0/24 to be translated but only block web from 10.2.100.0/24 & FTP 10.3.100.0/24 if it is destined for the server 10.1.1.1. If you remove those subnets from ACL 2 then they are not being translated at all which is out of scope.

Adding the access lists to the interfaces FastEthernet0/1 & FastEthernet0/1.3 provides a solution that allowed the traffic to be translated but only block those services.

[paul driver]

Hello @Tyson Joachims 

Humm... if you look i havent negated any subnet not to be natted ONLY the two hosts

Now the problem comes, the PC0 still can access the server www, same as PC2 can access FTP.

But if I deleve the nat command line, the ACL works.

so given the above my understanding is that the OP doesn’t want those two hosts from accessing the www & ftp server

[Tyson Joachims]

The requirements are directly below the network topology image:

1> I created NAT for 10.2.0.0/16 and 10.3.0.0/16 to access the server0.
2> Created ACL for 10.2.100.0 0.0.0.255 to not allow access server www
   Created ACL for 10.3.100.0 0.0.0.255 to not allow access server ftp

His original issue was getting those requirements to work together considering the ACL was on the FastEthernet0/0 interface in the outbound direction.

If you remove the host from the NAT ACL, they will no longer be translated to 10.1.50.50 but the ACL will indeed work. My solution allows both the translation to 10.1.50.50 while also blocking www & ftp for the respective subnets.

[Jonasye]

Thanks to all of you, maybe my question is not clear, but all your answers help me, now I think I'm clear on the relationship between ACL and NAT.

[paul driver]

Hello @Tyson Joachims @Jonasye 

 allows both the translation to 10.1.50.50 while also blocking www & ftp for the respective subnets

Apologies I don't want to dwell on the fact a solution has been provided which is viable, but i just like to state again there is no need to create any new ingress access-list or re-address the nat outside domain interface.

All that is required is to change the nat access-list accommodate the above, as the lan networks are non -routable and are hidden behind nat anyway, you just need to negate network translation for tcp www, ftp, ftp-data and allow everything else.

example:
access-list 101 remark NAT-ACL
access-list 101 deny tcp 10.2.0.0 0.0.255.255 host 10.1.1.1 eq www
access-list 101 deny tcp 10.3.0.0 0.0.255.255 host 10.1.1.1 range ftp-data ftp
access-list 101 permit ip 10.2.0.0 0.0.255.255 any
access-list 101 permit ip 10.3.0.0 0.0.255.255 any