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

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

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

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

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

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

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!

Hi

Spot on; thank you very much.

I will remember that.

Dion

Glad it helped.

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

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

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.

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

Arav

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.