Control traffic via ACL's

[Erik Jacobsen]

Hi,

I have a setup where I want to block traffic from one side and allow it from the other.

10.48.100.0/24  one side of the router (routed via 10.45.1.1) -  10.45.254.0 on the other side.

From the 10.48 scope I should only be able to reach 2 IP adresses on the 10.45.254.0 scope   .2 and .30

But from 10.45.254.0 I should be able to reach everything.

This is very simpel to do on a firewall, but I have some issues on a core 6500.

I have made a acl there look like this.

permit tcp any any established

permit ip 10.48.100.0 0.0.3.255 host 10.45.254.2
permit ip 10.48.100.0 0.0.3.255 host 10.45.254.30
deny ip 10.48.100.0 0.0.3.255 any
permit ip any any

I have a access-group in  on the 10.45.1.1 interface. (Vlan)

If I remove the top line, then 10.48.100 supnet is only allow to reach .2 .30 as it should.  BUT then I can not reach anything on the 10.48.100 subnet other than I come from those 2 IP's.

then I found the established command, and now I can reach every on the 10.48 subnet, but I also found out that 10.48 can also reach everything at 10.45.254, WHY is this possible?

Best regards,

Erik

[dan.cicioiu]

---- down

[Dan-Ciprian Cicioiu]

Hello Erik ,

The establish statement matches all the packets that have ack bit set.

The only packets that does not have ack bit set are the first packet in the three-way hand shake.

Also  you have set the acl on the wrong interface, because the source of the  packets with permit and deny (2,3,4 statements ) are on 10.48. and the  vlan is connected to 10.45. , so the source will be 10.45 on in of the  interfaces.

Could you paste a show access-list here to see if there is any match on that lines , maybe i misunderstood.

Dan

[Erik Jacobsen]

Hi Dan,

I'm not quite following you.

You are saying the source address is 10.45.1.1 because this is the way 10.48.100 is coming in.  But as long it is not nattet, then the source will always be 10.48.100

Also the ACL works in the permit and deny state, the problem it is working to well without the establish keyword.  Because it block the traffic in both directions.

When I use the establish line, then there is open both directions and this I don't understand.

Erik

[Dan-Ciprian Cicioiu]

Hi Erik ,

Is the setup like that :

10.45.254/24 <----------interface vlan x ( 10.45.1.1 ) | Cat 6500 | interface vlan y -------------> 10.48.100/24

Or can you draw somehow the setup

Dan

[cadet alain]

Hi Erik,

permit tcp any any established

permit ip 10.48.100.0 0.0.3.255 host 10.45.254.2
permit ip 10.48.100.0 0.0.3.255 host 10.45.254.30
deny ip 10.48.100.0 0.0.3.255 any

permit ip any any

An ACL is always looked at in a top down manner so if you have tcp traffic  it will be permitted inbound  as long as the ack bit is set.

But all other ip traffic(icmp,udp,etc) won't be permitted from outside inbound because of your last line except of course if it matches the 2nd and 3rd lines.

Regards.

[Jon Marshall · Accepted solution]

Erik

You are right, that shouldn'tbe happening.

To confirm, the only way for 10.48.x.x to reach 10.45.254.x is via vlan vlan interface with IP 10.45.1.1 ?

Also, you have applied the acl inbound ?

If so can you clear the counters from the acl and then from a 10.48.x.x address that should be denied can you initiate a tcp connection to a 10.45.254.x address and see which line is being hit in the acl ?

Jon

[Erik Jacobsen]

Hi,

Just to clarify for everyone my configuration:

interface fast0/0

ip address 10.45.1.1 255.255.255.0

ip access-group test in

!

interface fast0/1

ip address 10.45.254.1 255.255.255.0

!

ip route 10.48.100.0 255.255.255.0 10.45.1.2

!

ip access-list extended test

permit tcp any any established

permit ip 10.48.100.0 0.0.3.255 host 10.45.254.2
permit ip 10.48.100.0 0.0.3.255 host 10.45.254.30
deny ip 10.48.100.0 0.0.3.255 any

permit ip any any

I will clear the counters and see what is beeing hit.

Erik

[Erik Jacobsen]

Hi All,

Thanks for all your support, talking about beeing blind. I found out that my "ip access-group test in"  last time I put it on was 23:30 in the evening and I could not spell to "test"

So yes the access-list does work correctly now.

Best regards,

Erik