Access- List line vty 0 4

Hi, Can you answer the following:

- Where is the host (192.168.10.11) ? in you network?

- dou you test the extended ping of your router?

- You say: I can Ping.... so... the icmp packet is analized in phisical interfaces... no in vty interfaces..........remember: is a standar acl (no upper - protocols )

Please give me more information.

Regards Juan Carlos Spichiger

The address 192.168.10.11 is located on the LAN. This router is located in our DMZ, the address of the DMZ is

172.16.10.x All access through the vty is denied while this access list is > Hi,

Is there any NAT being done? Maybe the router is seeing a translated address rather than the original 192.168.10.11 address.

There's probably a debugging option you can enable that will log a message when the vty is refusing a telnet, but I don't know what it is offhand.

Please

give more information.

post the running-config...... without the passworf, off course.

regards Juan Carlos

Building configuration...

Current configuration : 1132 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname ! boot-start-marker boot-end-marker ! mmi polling-interval 60 no mmi auto-configure no mmi pvc mmi snmp-timeout 180 no aaa new-model ip subnet-zero ! ! ! ! ip cef no ip domain lookup ! ! ! ! interface FastEthernet0/0 description Connected to DMZ ip address 172.16.10.110 255.255.0.0 speed auto ! interface Serial0/0 description Connected Not configured ip address encapsulation frame-relay IETF no fair-queue service-module t1 remote-alarm-enable frame-relay interface-dlci 16 ! ip classless ip route 172.16.10.21 255.255.255.255 172.16.10.1 no ip http server ! ! access-list 91 permit 192.168.10.11 access-list 91 permit 192.168.10.12 access-list 91 permit 192.168.10.13 access-list 91 permit 192.168.10.14 access-list 91 permit 192.168.10.15 snmp-server community public RO snmp-server enable traps tty ! control-plane ! ! line con 0 line aux 0 line vty 0 4 access-class 91 in privilege level 2

login ! end

Juan Carlos wrote:

Building configuration...

Current configuration : 1132 bytes ! version 12.1 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname ! boot-start-marker boot-end-marker ! mmi polling-interval 60 no mmi auto-configure no mmi pvc mmi snmp-timeout 180 no aaa new-model ip subnet-zero ! ! ! ! ip cef no ip domain lookup ! ! ! ! interface FastEthernet0/0 description Connected to DMZ ip address 172.16.10.110 255.255.0.0 speed auto ! interface Serial0/0 description Connected Not configured ip address encapsulation frame-relay IETF no fair-queue service-module t1 remote-alarm-enable frame-relay interface-dlci 16 ! ip classless ip route 172.16.10.21 255.255.255.255 172.16.10.1 no ip http server ! ! access-list 91 permit 192.168.10.11 access-list 91 permit 192.168.10.12 access-list 91 permit 192.168.10.13 access-list 91 permit 192.168.10.14 access-list 91 permit 192.168.10.15 snmp-server community public RO snmp-server enable traps tty ! control-plane ! ! line con 0 line aux 0 line vty 0 4 access-class 91 in privilege level 2

login ! end

Juan Carlos wrote:

Do you have NAT? in the other side?

use the traceroute command but the other router and check the trace.

regards

Hi,

snipped-for-privacy@comcast.net schrieb:

so, this is the DMZ, right?

Where does the Serial0/0 point to? Towards the external net or towards the internal net?

Huh? You mean, that to reach ONE address inside the dmz-addressrange (172.16.0.0/16) the packet should be sent to ANOTHER address in that range? Well, strange, me thinks.

Anyway. I do not see ANY route towards 192.168.10.x nor do I see a way towards the internal network. Could it be, that the dmz is connected via a firewall which is, by default doing NAT (as the use of private addressing implies)?

Please, remove the accdess-list, enable the proper debugging for telnet access and THEN do the telnet. What source-address do you see then? Alternativly: the last access-list statement should be access-list 91 deny any log

Apply that one and have a look at the log-statements. They show the source-IP as well Mathias

I've done this when 172.16.10.1 is a firewall with a redirect for

172.16.10.21, and for some reason it wasn't properly proxy-ARPing for the redirected address. You could also configure a static ARP entry, but IP addresses tend to be more stable than MAC addresses.