I have a weird situation on some of the 857's on my VPN. When they start up I can telnet into their Dialer0 interfaces and login as per normal. However, once their crypto sessions are established telnet stops working on some of them (all my routers have same IOS. DSL firmware and have similar configs). I checked the traceroutes and what happens is that the last hop stops working, the last hop to the dialer interface. If I remove the crypto then telnet starts working immediately.
Any ideas ?
My Dialer0 interface:
ip ddns update hostname <my hostname>
ip ddns update SMS_DynDNS
ip address negotiated
ip access-group 101 out
ip mtu 1492
ip virtual-reassembly in
dialer pool 1
dialer idle-timeout 0
ppp authentication chap pap callin
ppp chap hostname <my hostname>
ppp chap password 0 <my password>
ppp pap sent-username <my hostname> password 0 <my password>
ppp ipcp dns request accept
access-list 102 remark DSL IN
access-list 102 remark CCP_ACL Category=1
access-list 102 permit esp any any
access-list 102 permit gre any any
access-list 102 permit udp any any eq isakmp
access-list 102 permit udp any any eq non500-isakmp
access-list 102 permit udp any any eq 10000
access-list 102 permit tcp any any eq 10000
access-list 102 permit icmp host 188.8.131.52 any
access-list 102 permit udp any eq domain any
access-list 102 permit tcp any eq domain any
access-list 102 permit tcp any eq www any established
access-list 102 permit tcp any any eq www
access-list 102 permit tcp any eq ftp-data any
access-list 102 permit tcp any eq ftp any
access-list 102 permit tcp any eq 69 any
access-list 102 permit udp any eq tftp any
access-list 102 permit tcp any eq 443 any
access-list 102 permit tcp any eq telnet any
access-list 102 permit tcp any any eq telnet
access-list 102 permit udp any eq ntp any eq ntp
access-list 102 permit tcp any range 11000 11025 any
access-list 102 permit tcp any any eq 8000
access-list 102 deny ip any any log
crypto ipsec client ezvpn SMS_VPN
group <group details>
peer <peer details>
username <login details>
xauth userid mode local
The 40. IP is used for the Lan side range. The 50. IP is a local loopback on the router.
access-list 100 remark CCP_ACL Category=16
access-list 100 permit ip 184.108.40.206 0.0.0.127 192.168.0.0 0.0.255.255
access-list 100 permit ip host 220.127.116.11 192.168.0.0 0.0.255.255
I wonder if the problem is perhaps associated with operating in network extension mode when the crypto comes up. Is there any indication of the telnet on the upstream VPN peer?
I also have a few port forwards setup on my routers to forward some web traffic to some of the devices on the lan side of the router. I now realized that when the Telnet stops working to the routers, those port forwards also sort of stop working.
On the router(s) I do a "show ip nat translations" and I can see the port translations, but the web pages do not display anymore and times out. It looks to me like all the traffic is now begin encoded as VPN traffic and can not be interpreted by the telnet/web clients.
I am stumped here, any further ideas ?
Perhaps it might help if you add a line at the very beginning of access list 100 that denies telnet traffic (before the other traffic is permitted). Give that a try, and if it helps then perhaps something similar might help the web traffic.
Thanks Richard, it made no difference unfortunately. I added
access-list 100 deny tcp any eq 23 any
access-list 100 deny tcp any any eq 23
As well as different versions with the 40. and 50. IP address ranges.
I am not coming up with any good explanation based on what I am seeing. Perhaps a fresh copy of the config might give me a better idea.
I made some progress, sort of ...
I added a nat entry to force telnet from Dialer0 to the Loopback0 interface:
ip nat inside source static tcp 50.x.x.1 23 interface Dialer0 23
and now telnet is working fine. When I find a router in the telnet-not-working-state and I add the entry, the telnet over the public interface starts working immediately.
I have no idea why this would resolve the problem for telnet. I guess the difference is that the traffice is begin forwarded from outside to inside, instead of being routed from outside to inside which encrypts it ?
Anyway, that has not solved the web port forward to the lan devices connected to the router. They still do not work while the crypto is up ( ip nat inside source static tcp 40.x.x.2 80 interface Dialer0 11025 ).
I tried NATting the traffic from Dialer0->Loopback0->LanDevice : did not work.
I tried NATting the traffic from Dialer0->Loopback0->NewLoopback1(ip nat outside)->LanDevice : did not work.
Thanks for updating us and letting us know that you have found a work around that makes it work. I am not clear why this gets it to work. I still suspect that it has something to do with network extension mode and something that the Easy VPN peer is doing or is specifying. But the important thing is that now you can get it to work.
I am still struggling with the web port forwarding, but am now completely out of ideas.
Any other ideas pop to mind guys ?