vpdn problem after upgrading to ios 12.3(14)

Repost of earlier question this time with the full config attached.

I been using the attached vpdn config on Cisco 837s for ages and it's always worked. However after upgrading a 837 from 12.3(7) to IOS 12.3(14) I can make a VPN connection to the router but I can only ping the router and not anything else on the remote network. If I switch back to an older IOS e.g. 12.3(7) it works, but when I switch to 12.3(14) it stops again. This is with exactly the same config file.

When I posted just the vpdn related bits of the config it was suggested that something else like a NAT rule might be causing the problem, so I've posted the full config. However note that the exact same config works fine with

12.3(7) and doesn't work with 12.3(14) so if there is an error in the NATing or elsewhere it must be a subtle one.

Incidentally nothing appears in the log or as an SNMP trap.

Any ideas? This one has me baffled.

JR

Config is:

- local network is 192.168.1.0/24

- there is an IPSEC VPN that shouldn't be interfering with vpdn

- IP addresses and passwords changed to protect the innocent!

no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname myrouter ! logging buffered 4096 enable secret ! username Router password username nsadmin password no aaa new-model ip subnet-zero ! ! ip inspect name myfw cuseeme timeout 3600 ip inspect name myfw ftp 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 !ip audit notify log !ip audit po max-events 100 !no ftp-server write-enable ! ! PPTP dialins ! ============ ! vpdn enable ! vpdn-group pptp ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 exit exit ! interface Virtual-Template1 ip unnumbered Ethernet0 peer default ip address pool default ppp encrypt mppe auto ppp authentication ms-chap ! ip local pool default 172.31.255.192 172.31.255.199 ! ! VPN to Llandudno (peer changed to 123.123.123.123) ! ================ ! crypto isakmp policy 1 encryption des hash sha authentication pre-share group 1 crypto isakmp key ThunderBolt address 123.123.123.123 ! crypto ipsec transform-set tr-null-sha esp-null esp-sha-hmac crypto ipsec transform-set tr-des-md5 esp-des esp-md5-hmac crypto ipsec transform-set tr-des-sha esp-des esp-sha-hmac crypto ipsec transform-set tr-3des-sha esp-3des esp-sha-hmac ! crypto map cm-cryptomap 1 ipsec-isakmp set peer 123.123.123.123 set transform-set tr-des-sha match address 120 ! no access-list 120 access-list 120 remark Site to Site VPN access-list 120 permit ip 172.31.255.0 0.0.0.255 192.168.123.0 0.0.0.255 access-list 120 deny ip 172.31.255.0 0.0.0.255 any ! ! Interfaces ! ========== ! interface Ethernet0 ip address 172.31.255.1 255.255.255.0 ip nat inside no ip mroute-cache hold-queue 100 out ! interface ATM0 no ip address no ip mroute-cache atm vc-per-vp 64 no atm ilmi-keepalive pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 1 ! dsl operating-mode auto ! 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 ppp chap password ppp pap sent-username password crypto map cm-cryptomap no ip route-cache no ip mroute-cache hold-queue 224 in ! ! NAT ! === ! ip nat inside source list 102 interface Dialer1 overload ! ip classless ip route 0.0.0.0 0.0.0.0 Dialer1 ip http server no ip http secure-server ! ! Access lists ! ============ ! no access-list 23 access-list 23 remark Allowed to manage the router access-list 23 permit 172.31.255.0 0.0.0.255 ! no access-list 102 access-list 102 remark Addresses to NAT behind router access-list 102 deny ip 172.31.255.0 0.0.0.255 192.168.123.0 0.0.0.255 access-list 102 permit ip 172.31.255.0 0.0.0.255 any ! no access-list 111 access-list 111 remark Incoming access from the Internet ! ping access-list 111 permit icmp any any administratively-prohibited access-list 111 permit icmp any any echo 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 ! VPN access-list 111 permit esp any any access-list 111 permit udp any any eq isakmp access-list 111 permit tcp any any eq 1723 access-list 111 permit gre any any ! Servers ! Allow VPN connections from Kinmel Bay access-list 111 permit ip 192.168.123.0 0.0.0.255 172.31.255.0 0.0.0.255 ! Deny the rest access-list 111 deny ip any any log ! dialer-list 1 protocol ip permit ! line con 0 exec-timeout 120 0 no modem enable stopbits 1 line aux 0 line vty 0 4 access-class 23 in exec-timeout 120 0 login local length 0 ! scheduler max-task-time 5000 ! banner motd | Pro-Networks Ltd

You require authorisation to connect to this device. If you are not authorised to connect to this device please disconnect now.

| ! end

Reply to
John Rennie
Loading thread data ...

[...]

I have similar problem when I upgrade my router to 12.4.1 ( from

12.3.8T6 ). I turn on the debug and it shows my packets from the VPDN interface are forwarded to the wrong interface when I access to any hosts outside of the router.

Maybe just a coincidence : the reason I switch to the 12.4 is to use the NAT Virtual Interface, and Cisco doc says this feature introduces in 12.3.14 which is the version you have problem. Don't know if there is anything to do between this problem and that new feature.

But it may be just something wrong in my config that I have not figured it out yet.

DT

Reply to
dt1649651

Unfrotunately they are forwarded to the WAN interface. If you read my yesterday post with topic "wrong path of connection is from PPTP" you can see the output debug.

I also put a packet capture at expected interface ( the internal one ) and found nothing there.

DT

Reply to
dt1649651

guys open a TAC case it seems that this is a possible bug.

Reply to
rave

Thanks, if you manage to make it work please post here!

When you say "forwarding to the wrong interface", which interface are they being forwarded to? Unless you count the virtual templates there are only two and surely it's not trying to route the packets out the ADSL line?

JR

Reply to
John Rennie

Just let you know, I just reload my router with 12.4.2T, same problem :(

DT

Reply to
dt1649651

Thanks. I eventually downgraded to 12.3(12) and that's fine.

JR

Reply to
John Rennie

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.