Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Is Extended ACLs working in two directions?

Hi,

I would like to know the following, and I hope one of you can help me:

If I apply an extended ACL stating that PC1 must not communicate with PC2, and apply to an outbound interface like this:

cisco(config-acl-whatever)# ip access-list extended host pc1 host pc2

...is it still possible for PC2 to start e.g. a telnet session to PC1?

1 ACCEPTED SOLUTION

Accepted Solutions
Silver

Re: Is Extended ACLs working in two directions?

IOS ACLs are not stateful unless you are using CBAC (IOS firewall) . What this means is:

1. your ACL will block traffic origination from .1 to .2

2. host .2 can originate communication to .1, but the reply packets from .1 to .2 get blocked, so no tcp sessions can be brought up. Stateless protocols that use udp and don't expect replies could work - .2 could syslog to .1, for example

8 REPLIES
Gold

Re: Is Extended ACLs working in two directions?

Hi Rasmus --

If you are trying to stop PC2 trying to connect to PC1 via telnet then just create a ACL on the PC1 side router denying port 23 from PC2.

> access-list deny tcp any host eq 23

Also, remember that when writing ACL's on Router IOS you need to use 'wild card masks' and on PIX IOS use normal mask i.e.

In PIX IOS > 195.100.50.0 255.255.255.0

In Router IOS > 195.100.50.0 0.0.0.255 (wild card mask)

Hope this helps --

New Member

Re: Is Extended ACLs working in two directions?

Hi,

Thanks for your answer, but what I really need to know is just whether traffic between the two computers will be completely blocked with an ACL stating that PC1 must not connect to PC2 or whether it will still be possible for PC2 to conect to PC1 ?

I can't explain it better than that, hope you'll understand my problem.

Rasmus

Gold

Re: Is Extended ACLs working in two directions?

Hi Rasmus,

OK, so what you are saying is that you don't want PC1 to connect to PC2 nor do you want PC2 to connect back to PC1 - correct ?

Let me give you a quick example (using numbered ACL’s)

In this example our aim is to deny any telnet session originating from Network A to hosts on Network B.

H1 Network A > e0 [ROUTER] e1 > Network B H2

So, we will need to apply the ACL on the Ethernet 0 of Network A in-bound

> interface ethernet0

> ip access-group 110 in

!

> access-list 110 deny tcp any any eq 23

> access-list 110 permit ip any any

Obviously on the above, we are denying any telnet access from H1 to H2 but permitting IP traffic.

Of course in your situation you want to block all traffic from PC1 to PC2 (or is it the other way round) then you can use the above > access-list 1 deny host [IP of PC1 or PC2] and apply it to the outbound interface of the router, it is always more efficient to filter outgoing packets then incoming packets.

Hope this helps out for you and let me know how you get on --

New Member

Re: Is Extended ACLs working in two directions?

Hi - and thanks for your patience and interest.

We are getting there, but I can see that I need to be somewhat more specific. I appologize for my explanations (must be driving you nuts), but I am from Denmark, and my English probably needs a little retraining :0)

I want to know the following about this command:

router(config)# access-list 110 deny host 172.16.0.1 host 172.16.0.2

I know that this command blocks traffic from 172.16.0.1 to 172.16.0.2, but does it also block traffic from 172.16.0.2 to 172.16.0.1?

Is the source/destinations only used to specify which computer starts the connection and prohibit that, or is it indifferent since traffic will be blocked both ways no matter which address is source and which address is destination?

Hope this makes you see what I mean,

Rgds,

Rasmus

Silver

Re: Is Extended ACLs working in two directions?

IOS ACLs are not stateful unless you are using CBAC (IOS firewall) . What this means is:

1. your ACL will block traffic origination from .1 to .2

2. host .2 can originate communication to .1, but the reply packets from .1 to .2 get blocked, so no tcp sessions can be brought up. Stateless protocols that use udp and don't expect replies could work - .2 could syslog to .1, for example

Silver

Re: Is Extended ACLs working in two directions?

Hi,

Just a small correction on item 2. This will apply for UDP as well not only TCP. UDP desn't require TCP 3-way handshake but still requires the reply.

Regards,

Mynul

Gold

Re: Is Extended ACLs working in two directions?

Hi Rasmus --

OK, Matt from the other post beat me to it - what he states is correct for your question.

Hope this helps - and no it's not driving me nuts as its a plesure helping out.

Regards - Jay.

New Member

Re: Is Extended ACLs working in two directions?

Just what I needed thanks a lot all of you.

Rasmus

128
Views
0
Helpful
8
Replies
CreatePlease to create content