ip access-group IN vs OUT (Wrong Forum previously)

Answered Question
Feb 1st, 2007

I am trying to understand the difference between adding an ACL to an interface with the ip access-group in ip access-group out statement. I have 'in' on one interface, and 'out' on another, and they seem to behave differently. Both of the interfaces end up going out to the internet. A firewall allows the 192.168.3.0/24 range out to the internet. So the 192.168.150.0/24 network gets NAT'd to 192.168.3.100-150 (Overloaded), and the 192.168.3.0/24 interface just keeps the same IP.

See Below:

interface Ethernet1/0

description Lab Network 192.168.150.x

ip address 192.168.150.1 255.255.255.0

ip access-group LAB_ACL in

ip nat inside

full-duplex

ntp disable

<-- cut -->

ip access-list extended LAB_ACL

remark

remark #######################################################

remark

permit ip 192.168.150.0 0.0.0.255 host 4.2.2.1

permit ip 192.168.150.0 0.0.0.255 host 4.2.2.2

permit ip 192.168.150.0 0.0.0.255 65.200.222.0 0.0.0.63

permit ip 192.168.150.0 0.0.0.255 65.200.10.0 0.0.0.255

remark #######################################################

remark

remark Deny all

deny ip any any log

remark #######################################################

*******************

interface FastEthernet0/1

description Corporate NAT Interface

ip address 192.168.3.2 255.255.255.0

ip access-group ACL_allowed out

ip nat outside

speed 100

full-duplex

<-- cut -->

ip access-list extended ACL_allowed

remark

remark #######################################################

remark Deny standard microsoft ports

deny tcp any any eq 135

deny tcp any any eq 137

deny tcp any any eq 138

deny tcp any any eq 139

deny udp any any eq 135

deny udp any any eq netbios-ns

deny udp any any eq netbios-dgm

deny udp any any eq netbios-ss

deny tcp any any eq 445

deny udp any any eq 445

remark

remark #######################################################

remark Permit only traffic with local network

permit ip 192.168.3.0 0.0.0.255 any

remark

remark #######################################################

remark Deny all

deny ip any any log

remark #######################################################

I have this problem too.
0 votes
Correct Answer by acomiskey about 9 years 8 months ago

Think of it as this...

"in" is traffic into the port

"out" is traffic out of the port

Therefore you have to be careful when you write your acl's that your source and destination are not reversed.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (6 ratings)
Loading.
Richard Burts Thu, 02/01/2007 - 07:38

Tahir

I agree that the implications of access-group in and access-group out are subtle and sometimes a bit difficult to understand. It helps me to think about them this way: in and out are from the prespective of the router. So an access-group out is traffic that the router is sending out to the devices on that interface segment and access-group in is receiving traffic from the devices on that interface segment.

So your first access list is on interface Ethernet1/0 and is applied inbound, so the devices on that subnet are sending - and so the source address should be 192.168.150.x. The access list is written with 192.168.150.0 as the source and the access list should work.

Your second access list is on interface FastEthernet0/1 and is applied out, so the 192.168.3.x should be the destination. But the permit statement (permit ip 192.168.3.0 0.0.0.255 any) is using it as the source. So it looks to me like this access list should not be working unless you assign it inbound or reverse the addresses in the access list.

HTH

Rick

t.khan Thu, 02/01/2007 - 07:51

Rick,

That is the understanding I was under, however it does not seem to work that way. If I reverse the second access-group by changing it from 'out' to 'in', it fails.

Keeping the exact same access list I get these errors:

ip access-list extended ACL_allowed

remark

remark #######################################################

remark Deny standard microsoft ports

deny tcp any any eq 135

deny tcp any any eq 137

deny tcp any any eq 138

deny tcp any any eq 139

deny udp any any eq 135

deny udp any any eq netbios-ns

deny udp any any eq netbios-dgm

deny udp any any eq netbios-ss

deny tcp any any eq 445

deny udp any any eq 445

remark

remark #######################################################

remark Permit only traffic with local network

permit ip 192.168.3.0 0.0.0.255 any

remark

remark #######################################################

remark Deny all

deny ip any any log

remark #######################################################

<--cut-->

interface FastEthernet0/1

description Corporate NAT Interface

ip address 192.168.3.2 255.255.255.0

ip access-group ACL_allowed IN <--- Changed from out to in.

ip nat outside

speed 100

full-duplex

Below are all the UDP DNS requests and NTP requests that now fail when changed to 'IN'

Feb 1 2007 10:46:50: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 192.5.41.41(123) -> 192.168.3.2(123), 1 packet

Feb 1 2007 10:46:59: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48279), 1 packet

Feb 1 2007 10:47:19: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48280), 1 packet

Feb 1 2007 10:47:39: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48282), 1 packet

Feb 1 2007 10:47:47: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48284), 1 packet

Feb 1 2007 10:48:01: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48285), 1 packet

Feb 1 2007 10:48:14: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48287), 1 packet

Feb 1 2007 10:48:16: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48288), 1 packet

Feb 1 2007 10:48:46: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48290), 1 packet

Feb 1 2007 10:48:51: %SEC-6-IPACCESSLOGP: list ACL_allowed denied udp 4.2.2.2(53) -> 192.168.3.105(48291), 1 packet

Below are the IP NAT translations that show the .3.x network (NATd for internet) to the 150.x network

router>show ip nat translatations

--- 192.168.3.79 192.168.2.79 --- ---

--- 192.168.3.80 192.168.2.80 --- ---

udp 192.168.3.105:1026 192.168.150.50:1026 4.2.2.2:53 4.2.2.2:53

udp 192.168.3.105:48282 192.168.150.50:48282 4.2.2.2:53 4.2.2.2:53

udp 192.168.3.105:48284 192.168.150.50:48284 4.2.2.2:53 4.2.2.2:53

udp 192.168.3.105:48285 192.168.150.50:48285 4.2.2.2:53 4.2.2.2:53

udp 192.168.3.105:48287 192.168.150.50:48287 4.2.2.2:53 4.2.2.2:53

udp 192.168.3.105:48288 192.168.150.50:48288 4.2.2.2:53 4.2.2.2:53

t.khan Thu, 02/01/2007 - 08:44

I should also note that there is NAT on the Fastethernet 0/1 interface. (It is in the config), but that all the 150.x traffic is nat'd to a pool from 192.168.3.100-192.168.3.105, then sent out the 192.168.3.x interface. I am not sure if that has an effect on this access-group problem.

franklaszlo Thu, 02/01/2007 - 10:47

yes, NAT indeed has an implication on the processing of ACLs. The router first translate the address of the egress packet and checks the ACL afterwards. Therefore, in your case the source ip of the outgoing packet is picked from the 192.168.3.100-192.168.3.105 pool, and the out ACL will allow this traffic sent out. Eventually, in the case of NAT you have to design ACLs by considereing this.

For further explanation of the order of operation check this : http://www.cisco.com/warp/public/556/5.html

t.khan Thu, 02/01/2007 - 12:07

So what ultimately is the difference between an 'IN' and an 'OUT' in the ip access-group command? It still does not make sense to me.

Thanks!

rdessert Thu, 02/01/2007 - 12:26

The difference in applying an ACL in or out is pretty easy. When you apply an ACL "in", the router examines all traffic it RECEIVES on the interface against the ACL.

When you apply an ACL "out" on an interface the router examines any traffic attempting to leave that interface against the ACL.

Correct Answer
acomiskey Thu, 02/01/2007 - 12:27

Think of it as this...

"in" is traffic into the port

"out" is traffic out of the port

Therefore you have to be careful when you write your acl's that your source and destination are not reversed.

franklaszlo Thu, 02/01/2007 - 13:54

just another explanation :

- "into" means packets received from the "cable" attached to the port;

- out means packets to be forwarded towards destinations reachable through the "cable"

t.khan Thu, 02/01/2007 - 13:58

Does 'IN' and 'OUT' change depending on which direction the packets are flowing. If host A talks to Host B over the interface, does the access list work the same if host B talks to host A?

franklaszlo Thu, 02/01/2007 - 14:08

no, not at all. Consider an smtp communication for example :

Host----port a [router]---- Server

when you want to allow the host to send mail to the server, you would write an in acl on port a :

permit tcp host (host ip) host (server ip) eq smtp

on the other hand, to allow the server to reply, you would create an out acl like this :

permit tcp host (server ip) eq smtp host (host ip)

franklaszlo Thu, 02/01/2007 - 14:10

sorry, the short answer is YES, it does change...but the example is correct :-)

t.khan Fri, 02/02/2007 - 06:23

I guess I understand. So you are saying if I create the above ACL, I cannot get responses unless I create the appropriate out ACL? I though the OUT acl was just after the router processed the packet. In other words, I send a packet 'in' and interface, the router decides if it is ok to pass, it does, then NAT's the packet, then it compares it against the 'out' acl. Is this correct?

Can 'in' be both sides of an interface, because technically it can come 'in' both sides.

acomiskey Fri, 02/02/2007 - 11:12

You're just messing with us now...

Just kidding.

Out would be out of the physical port or onto the wire.

=========================================

Example 1: IN

Host A -------> fa0/1 fa0/xx -------> Host B

int fa0/1

ip access-group 101 in

-in this scenario Host A would be source when you write your acl, host B would be destination.

-acl would inspect traffic from A to B because traffic is coming "in" the interface where the access-group is applied

=========================================

Example 1: OUT

Host A <------- fa0/1 fa0/xx <------- Host B

int fa0/1

ip access-group 101 out

-in this scenario Host B would be source when you write your acl, host A would be destination.

-acl would inspect traffic from B to A because traffic is coming "out" the interface where the access-group is applied

=========================================

Any better?

t.khan Fri, 02/02/2007 - 12:58

That makes sense. My problem with the whole issue was that traffic still is able to flow back an interface, I just assume that the ACL allows originated traffic back in. If you look at the above config that I had originally posted, it didn't make sense. It seemed that the ACL was backwards, but it was the NAT playing a role. I apologize for all the hassle. I do appreciate this forum, and thank everyone who contributed.

Actions

This Discussion