IP ACL and TCP ACL .. What's the differences?

[steven.pw.lau]

Hi,

I have a few questions on ACL.

1. For PIX ACL, Let's say I would like to host a Web Server in the Internal Network (just to make my question simpler), and I do not use PAT, but only static NAT

static (inside, outside) 202.188.100.1 10.1.1.1 netmask 255.255.255.0

access-list acl_out permit tcp any 10.1.1.1 eq 80

access-group acl_out in interface outside

Does the above equivalent to

static (inside, outside) 202.188.100.1 10.1.1.1 netmask 255.255.255.0

access-list acl_out permit ip any 10.1.1.1

access-group acl_out in interface outside

2. For IOS ACL, is it possible to block access from Network A (10.1.1.0/24) to Network B (10.1.2.0/24) but allow access from Network B to Network A? How do I do it?

Thanks.

[ciscokrishna]

Hi,

Coming to your first question, the config 1 is different from config 2. The key word TCP or IP made all the difference. TCP means only TCP connections (connections where 3way handshake is done). TCP connection is reliable and the talking parties will have a contorl over the communication. where as IP means any IP protocol. It can include TCP or UDP. Let me put it this way, in the first config set, the ACL will allow only TCP connection on port 80 to the destination 10.1.1.1. In the second config set, the ACL will permit both TCP as well as UDP connections on all the ports to the 10.1.1.1 destination.

Hope this cleared your doubt. Coming to the second question, it is very much possible. Lemme give you a small example (below)

ethernet0 ------------- ROUTER -------------- serial0

10.1.1.0/24 10.1.2.0/24

NET A NET B

Now you can put an access-list from NET A to NET B to DENY the traffic and apply it on the e0 interface inbound. put one more access-list from NET B to NET A PERMITing the traffic and apply it on s0 interface inbound. This shud help you.

Any comments are welcome.

[ciscokrishna]

sorry about the diagram in the above post. there was some probelm with space. please consider 10.1.2.0/24 as NET B on the serial interface side.

e0----------------ROUTER----------------S0

1.0/24---------------------------------2.0/24

NET A --------------------------------NET B

[steven.pw.lau]

Hi,

Thanks for the 1st answer.

For the 2nd one, if there's only a DENY statement from NET A to NET B, does this also means that NET B would not be able to access NET A (assuming that a PERMIT ANY ANY is used after that)?

Correct me if I'm wrong. If a DENY from NET A to NET B is used and PERMIT from NET B to NET A is used, traffic from NET B can traverse to NET A but the reply packets would be blocked because the router does not permit traffic from NET A to NET B? Does this affect the data communication from NET B to NET A?

Thanks again.

[paddyxdoyle]

You are correct, these access-lists would block your traffic.

You need to use the established command or reflexive access lists me thinks, see post below.

...PJD

[paddyxdoyle · Accepted solution]

Hi,

1. Firstly your ACL is slightly wrong, you need to permit connections to the public address of your devices and not the private when permitting traffic from the outside.

The short answer to your first question is no, if you permit tcp port 80 in your access list then you are permitting just that, if you permit ip in your access-list then you are permitting all IP based protocols including all TCP ports, all UDP ports and all ICMP.

2. You can achieve this by using either the established key word in your access-list or reflexive access-lists.

Network B to A ACL

---

permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255

Network A to B ACL

---

permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 any established

The above means that any traffic can pass from network B to network A, however only established connections (packets with ACK bit set) are allowed from B to A.

The other method is using reflexive access-list which are stateful access-lists. When traffic travels from one network to another a dynamic access list is created, traffic is only allowed back to the source network if a dynamic entry is present in the table containing the same source and destination IP information. A flexive access-list works in one direct so from A to B, if you wanted to allow B to talk to A you would have to configure specific static access-list entries.

HTH

PJD

[ciscokrishna]

Hi,

Paddy, i think i would differ with your answer in point 2. permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 any established. Here it shows it allows only connection for established sessions. here is a simple explanation. if B is initiating a connection, it will have SYN and the reply from A will be SYNACK. only after the SYNACK is received by B wud the connection reach established state. So for the first reply packet A is sending to B, the status will be SYNACK (embryonic, not established) because the ACK for the SYN packet has not reached B yet. so this connection is dropped by the access list and the session would never reach established state.

The only method for accomplishing this task is to use any stateful deivce which knows the state table and session level.

Do correct me if i am worng.

[paddyxdoyle]

Ok then, you asked for it :)

Have a look at the following link, specifically the bit titled "Allow Only Internal Networks to Initiate a TCP Session".

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a0080100548.shtml

I understand what you are saying though as logically when the inital three way handshake is established packets with SYN and SYN/ACK bits set will be sent through both access-lists so logically the connection should fail....

However my theory is that the fact the SYN/ACK has the ACK bit in it, the access-list will allow it through as its is specifically looking for ACKs.

However the access-list won't allow the SYN bit through so a host on the opposite router couldn't initiate a TCP handshake to a host on the local net.

It defo works tho' as i have it configured on one of our old VPN routers.

HTH

Paddy

[ciscokrishna]

Thanks a lot for the info Paddy. This was very informative. I was not aware that it would work this was as I have never tried this sort of connection.

[paddyxdoyle]

No problem, have a good day!