06-10-2001 08:05 PM - edited 03-08-2019 08:21 PM
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.
06-14-2001 07:07 AM
I havent seen nor heard of that behavior. Are you sure your ACLs allow it? Have you called TAC on it yet?
06-14-2001 07:17 AM
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.
11-14-2001 09:36 PM
Did you ever get a resolution to this?
11-14-2001 09:51 PM
I, too, would be interested in hearing if this issue had any resolution.
11-19-2001 10:47 PM
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. ;-)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide