Cisco 800 DSL - Public telnet access

Unanswered Question
Jan 16th, 2008

Hi

I have the following config that work's just great but i am unable to telnet into the device remotely. I have tried setting the telnet interface to Dialer1 but this does not work plus have also tried the following access list, that also does not work. access-list 111 permit tcp any any eq telnet.

What and where do i need it to get this to work.

!

version 12.3

no service pad

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname Springfield

!

boot-start-marker

boot-end-marker

!

enable secret 5 xxxxxxxxxxxxxxxxxxxxxxxxx

!

no aaa new-model

ip subnet-zero

ip name-server 212.74.112.66

ip name-server 212.74.112.67

ip dhcp excluded-address 192.168.1.3

ip dhcp excluded-address 192.168.1.1 192.168.1.99

!

ip dhcp pool CLIENT

network 192.168.1.0 255.255.255.0

default-router 192.168.1.3

dns-server 212.x.x.66 212.74.112.67

lease 0 2

!

ip inspect name myfw cuseeme timeout 3600

ip inspect name myfw ftp timeout 3600

ip inspect name myfw http timeout 3600

ip inspect name myfw rcmd timeout 3600

ip inspect name myfw realaudio timeout 3600

ip inspect name myfw tftp timeout 30

ip inspect name myfw udp timeout 15

ip inspect name myfw tcp timeout 3600

ip inspect name myfw h323 timeout 3600

!

!

!

!

!

!

interface Ethernet0

ip address 192.168.1.3 255.255.255.0

ip nat inside

hold-queue 100 out

!

interface ATM0

no ip address

atm vc-per-vp 64

no atm ilmi-keepalive

dsl operating-mode auto

pvc 0/38

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

!

interface Dialer1

ip address negotiated

ip access-group 111 in

ip nat outside

ip inspect myfw out

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication chap pap callin

ppp chap hostname xxxxxxxxxxxxxxxxxxxxxxxx

ppp chap password 7 xxxxxxxxxxxxxxxxx

ppp pap sent-username xxxxxxxxxxxxxxxxxxx password 7 xxxxxxxxxxxxxxx

hold-queue 224 in

!

ip nat inside source list 102 interface Dialer1 overload

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

ip route 172.16.0.0 255.255.0.0 192.168.1.99

ip http server

no ip http secure-server

!

access-list 102 permit ip any any

access-list 111 permit icmp any any administratively-prohibited

access-list 111 permit icmp any any echo-reply

access-list 111 permit icmp any any packet-too-big

access-list 111 permit icmp any any time-exceeded

access-list 111 permit icmp any any traceroute

access-list 111 permit icmp any any unreachable

access-list 111 permit esp any any

access-list 111 permit udp any any eq isakmp

access-list 111 permit gre any any

dialer-list 1 protocol ip permit

!

!

line con 0

transport preferred all

transport output all

stopbits 1

line vty 0 4

exec-timeout 120 0

password 7 xxxxxxxxxxxx

login

length 0

transport preferred all

transport input all

transport output all

!

scheduler max-task-time 5000

end

Springfield#

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
Richard Burts Wed, 01/16/2008 - 12:08

Dion

The first thing that I notice is that the inbound access list (111) does not have any entry for inbound telnet (or any other TCP protocol). I would think that the access list in your post should fix this.

If you add that line in the access list and it still does not work then we need to look further.

What address are you telnetting from? And what address are you telnetting to? When you attempt to telnet do you get a prompt? What kind of message do you get when you attempt telnet?

Also I notice that the inbound access list is set up for IPSec (permits for esp and for isakmp) but I do not see any IPSec in the config. Can you clarify this?

HTH

Rick

dionh Wed, 01/16/2008 - 12:23

Hi Rick

Thanks for the reply; "access-list 111 permit tcp any any eq telnet" make's no difference.

I scan port 23 from the internet and it's not open. (port closed)

The IPSec stuff is needed for a VPN cleint behind the firewall to function.

I thought it might be something to do with the ATM and Dialer interface and how there binded; but i have tried "ip telnet source-interface Dialer 1" and ip telnet source-interface ATM 0" with and without the above access list for telnet.

Dion

Richard Burts Wed, 01/16/2008 - 12:40

Dion

If you put the statement into access list 111 to permit tcp/telnet, and then attempt telnet, and then do show access-list 111, are there any hits showing in the access list? This will help demonstrate whether the telnet is getting to the router.

For now I would suggest not trying to use ip telnet source-interface. Just let the router default about which source interface it will use (and if you want to use a source interface command then I believe that dialer is the one that you want - since the ATM interface has no ip address it would not work as a source interface)

Also please answer the question about where/what address are you telnetting from and what address are you telnetting to?

HTH

Rick

dionh Wed, 01/16/2008 - 13:04

Hi Rick

using the following url to test the port:

http://www.t1shopper.com/tools/port-scanner/

I am getting matches with access-list 111 - see below each time I test it goes up by 2.

100 permit tcp any any eq telnet (24 matches)

have also removed the telnet Dialer1 so it's just using the defaults now.

destination of router is : 80.42.235.20

Access list now reads:

access-list 102 permit ip any any

access-list 111 permit icmp any any administratively-prohibited

access-list 111 permit icmp any any echo-reply

access-list 111 permit icmp any any packet-too-big

access-list 111 permit icmp any any time-exceeded

access-list 111 permit icmp any any traceroute

access-list 111 permit icmp any any unreachable

access-list 111 permit esp any any

access-list 111 permit udp any any eq isakmp

access-list 111 permit gre any any

access-list 111 permit tcp any any eq telnet

access-list 112 permit tcp any any eq telnet

dialer-list 1 protocol ip permit

Dion

Richard Burts Wed, 01/16/2008 - 13:12

Dion

It is helpful to know that if you put the statement into the access list that you are seeing hits in the access list. That does demonstrate that the packets are getting there.

If you attempt telnet to the router address (and would I be correct to assume that 80.42.235.20 is the address dynamically assigned to the dialer) what response do you get? do you get a prompt? do you get some message? does it just hang?

HTH

Rick

dionh Wed, 01/16/2008 - 13:31

Hi Rick

This is the message back;

C:\Documents and Settings\Administrator>telnet 80.42.235.20

Connecting To 80.42.235.20...Could not open connection to the host, on port 23:

Connect failed

Note: I can access other telnet servers from this box that are out on the internet.

Dion

dionh Wed, 01/16/2008 - 13:42

BTW: it works from a PC on this side of the network you get the prompt. ie . telnet 80.42.235.20 works but not from a remote device on the internet.

Springfield#show ip interface brief

Interface IP-Address OK? Method Status Prot

ocol

ATM0 unassigned YES NVRAM up up

Dialer1 80.42.235.20 YES IPCP up up

Ethernet0 192.168.1.3 YES NVRAM up up

Virtual-Access1 unassigned YES unset up up

Virtual-Access2 unassigned YES unset up up

Paolo Bevilacqua Wed, 01/16/2008 - 13:58

Hi,

your ACL 102 is causing that. Never use "any" in NAT ACLs.

Replace it with an acl, even a standard one, permitting inside addresses only.

Hope this helps, please rate post if it does!

dionh Wed, 01/16/2008 - 14:31

Hi

Spot on; thank you very much.

I will remember that.

Dion

Paolo Bevilacqua Thu, 01/17/2008 - 01:45

Glad it helped.

Please remember to rate useful posts with the scrollbox below! (log in to see it).

aravindhs Thu, 01/17/2008 - 01:45

Hi paolo,

I agree with you that 'any any' should not be used in a NAT ACL. But I do not understand how it would cause telnet to not work from the Internet. The requests would be coming in from the Egress Dialer interface and the ACL won't be referenced at all as the NAT inside domain is their inside LAN interface. Could you please clarify ?

Cheers

Arav

Paolo Bevilacqua Thu, 01/17/2008 - 02:11

It used to work in older IOS, then cisco changed something in NAT code (the NVI perhaps,I'm not sure ). Since then, ACLs with "any" do cause outside connections to fail.

Perhaps "any" do cause some kind of nat to be attempted to packets coming from outside too.

Bottom line, configure by the book, and it will work.

aravindhs Thu, 01/17/2008 - 04:13

Thanks Paolo ! That is something interesting. I have rated your helpful comment too.

Arav

dmendoza Thu, 02/07/2008 - 11:35

Thanks for your help, I was very frustated about this problem.

I was using the word 'any' as source because I have a lot of internal networks.

Damian.

Actions

This Discussion