cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
853
Views
0
Helpful
5
Replies

Telnet from public internet

melbourne.wells
Level 1
Level 1

I've recently updated to IOS 12.2(1) on a Cisco 1605R in order to take advantage of GRE and a few other VPN features. Unfortunatly I seem to have lost telnet access to the router via the interface configured for public internet access from non-private ip addresses. This interface is currently configured to do NAT/PAT as an outside interface. I can create a PPTP session to a VPN server behind the NAT and then telnet into the router using the private OR public side IP with no problems, however telnet to the public interface from any non-private IP results in a TCP session that never connects. Have there been any changes with the default functioning of telnet and/or NAT & PAT in the new IOS that would cause this? Thanks for any assistance.

5 Replies 5

murabi
Level 4
Level 4

I haven’t seen nor heard of that behavior. Are you sure your ACL’s allow it? Have you called TAC on it yet?

ACL's are wide open. TAC is currently looking at the problem so as soon as I get word I'll post the results. Thank you for the response - if anyone comes up with a brain wave on this one, post it here (lets see if the userbase can beat TAC response) :P I'll be checking here fairly often.

Did you ever get a resolution to this?

I, too, would be interested in hearing if this issue had any resolution.

Actually yes I did - I love TAC.

Apparently "access-list 1 permit any" is not a nice thing to have in a configuration when applied to the outside NAT interface.

The Official TAC answer was… “The access list you have specified is too broad and this can confuse the NAT program”

Ok, fair enough. I changed the access list to “access-list 1 permit x.x.x.x” and presto! - inbound telnet on the public side interface started working again. The only thing I have to say in my defense is... "’access-list 1 permit any’ worked on the older IOS images” ;-)

Interestingly enough static mappings and private IP NAT/PAT translations were unaffected and worked normally with this "access-list 1 permit any" setup. Anyone care to point out the evils of this in an access list for NAT? I'm sure there is some horrible security hole involving proxy arp (or something else) for my original access list. I'd look it up myself - but its rather late and all I really want right now is the spoon fed, cotton candy answer. ;-)