cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
906
Views
6
Helpful
11
Replies

Simple ACL problem

xianglingjs
Level 1
Level 1

On router there is a simple access list configured:

Router01#sh run int vlan51

Building configuration...

Current configuration : 250 bytes

!

interface Vlan51

description Storage management

ip address 141.x.x.x.255.255.240

ip access-group Vlan51-Storage-In in

no ip redirects

standby 20 ip 141.228.228.3

standby 20 timers 2 6

standby 20 priority 110

standby 20 preempt

end

Router#sh ip access Vlan51-Storage-In

Extended IP access list Vlan51-Storage-In

permit udp any eq 1985 host 224.0.0.2 eq 1985 (24177008 matches)

permit eigrp any any (31695573 matches)

permit icmp any any echo (7687 matches)

permit icmp any any echo-reply (145 matches)

permit tcp 141.x.x.x.0.0.15 any log (77085643 matches)

permit udp 141.x.x.x.0.0.15 any

deny ip any any log (100831 matches)

When I initiate a telnet session from 10.206.63.146 to 141.x.x.1, it is blocked as expected:

May 29 22:06:01.946 JST: %SEC-6-IPACCESSLOGP: list Vlan51-Storage-In denied tcp 10.206.63.146(55629) -> 141.x.x.1(1494), 1 packet

Strange thing happens when I telnet from 10.194.102.21. I can telnet to 10.228.228.1 and there is no log for it!

Can anybody give me a hint on why it is not blocked? Thanks!

11 Replies 11

dominic.caron
Level 5
Level 5

You are having a redundancy issue.

You are trying to telnet the router, not a host in the vlan. Host 10.206.63.146 is arriving to your .1 from the .2 router. ACL is apply inbound on the vlan.

When host 10.194.102.21 telnet 10.228.228.1, it must be arriving from another interface on the same router(the .1). The ACL is not apply in that case.

hope this is clear...kind of hard to explain without a whiteboard!

Thanks for the explanation Dominic. But the problem is .2 router is applying the same access list :

Router51#sh run int vlan51

Building configuration...

Current configuration : 225 bytes

!

interface Vlan51

description Storage management

ip address 141.228.228.2 255.255.255.240

ip access-group Vlan51-Storage-In in

no ip redirects

standby 20 ip 141.228.228.3

standby 20 timers 2 6

standby 20 preempt

end

Router51#sh ip access Vlan51-Storage-In

Extended IP access list Vlan51-Storage-In

permit udp any eq 1985 host 224.0.0.2 eq 1985 (24168593 matches)

permit eigrp any any (31702336 matches)

permit icmp any any echo (3862 matches)

permit icmp any any echo-reply (173 matches)

permit tcp 141.228.228.0 0.0.0.15 any log

permit udp 141.228.228.0 0.0.0.15 any (3 matches)

deny ip any any log (43565 matches)

No mater which interface it comes in. Thus the telnet traffic also not able to enter the .2 router no mater from 10.206.63.146 or 10.194.102.21, right?

Hi .. I don't think you are traversing the interface where the access-list is applied .. CAn you post a tracert from 10.206.63.146 to the hosts behind interface Vlan51

No

Your problem is in the way you see your ACL in the network. Here come the ascii art :)

Router A Router B

| | | |

intVlan1 intVlan2 intVlan1 intVlan2

| | | |

-----ACL in -------ACL in

| |

---<---<---Packet---<---<---

Let's say the host you are pinging from is in vlan2. If active router is RouterA, your icmp never to accros the ACLin. ACL is apply to traffic comming from the vlan. In this case. Your ping is routed from intvlan1 to intvlan2 but never go on the vlan1.

In case2, if active router is routerB and the .1 of vlan1 is routerA. You traffic will be router from vlan2 to vlan 1 on routerB. Router B will then forward the ping to routerA on vlan1. RouterA will apply the inbound ACL and deny the trafic.

ACL is realy apply between the router interface and the vlan

Router Interface -----|ACL|-----VLAN

The ACL will work for all host other than the vlan routers.

Sniff...my art

...........Router A ..........Router B

..........|........| ........| .......|

.......intVlan1 intVlan2 intVlan1 intVlan2

..........|........|.........|........|

.......-----ACL in.......-------ACLin |

..........|..................|........|

..........---<---<---Packet--<......SourceHost

Richard Burts
Hall of Fame
Hall of Fame

Mengdi

I believe there is some information that we do not have that is important in solving this question. In particular I believe we need some information about the topology of the network. From what you posted it is obvious that address 10.206.63.146 get to 141.228.228.1 through interface vlan 51 and the access list is applied. But we do not know where address 10.194.102.21 is located or what interface it uses to get to the router. The address appears to be in a different subnet, and may be getting to the router on a different interface. This may be why that telnet is successful (there may be a different access list or there may be no access list on that interface). If the telnet does not enter the router on interface vlan 51 then access list Vlan51-Storage-In will not be applied.

The access list Vlan51-Storage-In will only examine traffic that comes into the router on interface vlan 51. If traffic comes in on any other interface it will not be examined by access list Vlan51-Storage-In.

HTH

Rick

HTH

Rick

Ricks explanation sounds correct. I would recommend debugging your incoming connections and see what IP address is requesting the telnet session...

-Joe

Wired things come here, the trace routes are shown below.

C:\>ipconfig

Windows 2000 IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : xxxxxxx

IP Address. . . . . . . . . . . . : 10.206.68.52

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.206.68.253

C:\>tracert 141.228.228.1

Tracing route to 141.228.228.1 over a maximum of 30 hops

1 <10 ms <10 ms <10 ms 10.206.68.253

2 <10 ms <10 ms <10 ms 10.206.3.49

3 <10 ms <10 ms <10 ms 10.206.3.62

4 <10 ms <10 ms <10 ms 10.206.8.130

5 1 ms <10 ms 1 ms 10.207.3.21

6 1 ms 1 ms 1 ms 141.228.228.1

Trace complete.

C:\>ipconfig

Windows 2000 IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : xxxxxx

IP Address. . . . . . . . . . . . : 10.206.63.146

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 10.206.63.253

C:\>tracert 141.228.228.1

Tracing route to 141.228.228.1 over a maximum of 30 hops

1 <10 ms <10 ms <10 ms 10.206.63.253

2 <10 ms <10 ms <10 ms 10.206.3.5

3 <10 ms <10 ms <10 ms 10.206.3.22

4 <10 ms <10 ms <10 ms 10.206.8.130

5 1 ms <10 ms 1 ms 10.207.3.21

6 1 ms 1 ms 1 ms 141.228.228.154

7 1 ms 1 ms 1 ms 141.228.228.1

There is no policy-based routing on device 10.207.3.21. I can not see the reason why the traffic from the two different source takes two different path.

Do a sh ip route 141.228.228.1 on the 10.207.3.21 router.

I bet you have equal cost route to the destination network and the routing protocol is loadbalancing over those link.

yes, it's true. So that means if I cleared the CEF cache things will be different?

Mengdi

Even if you clear the CEF cache there will still be two paths toward that destination. Over time some traffic will probably use one path and some other traffic will probably use the other path. So when you create access lists to control certain types of traffic you need to evaluate whether there are alternate paths and determine which interfaces the traffic might arrive on and configure appropriate access lists and assign them to each of the interfaces.

So especially for controlling telnet access you are generally better off not to try to control telnet access via access list on the interface and to use a standard access list assigned as access-class on the vty ports. One advantage of using access-class is that it applies no matter which interface the traffic arrived on.

HTH

Rick

HTH

Rick