10-29-2009 07:23 AM
Hello! Our customer has a remote access server (cisco2811 running 12.4(20)T4) and RA is in following configurations:
vpdn enable
!
vpdn-group 1
! Default PPTP VPDN group
accept-dialin
protocol pptp
virtual-template 2
local name PPTP
interface Virtual-Template1 type tunnel
ip unnumbered FastEthernet0/0
ip virtual-reassembly
zone-member security LAN
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC_Profile
!
interface Virtual-Template2
ip unnumbered FastEthernet0/0
ip virtual-reassembly
zone-member security LAN
peer default ip address pool PPTP_Pool
ppp encrypt mppe auto
ppp authentication ms-chap ms-chap-v2 PPTP_list
so both pptp clients and vpn clients can connect. The problem is that local lan is not accessible from either pptp or ipsec remote nodes. Only router interfaces, not lan hosts. I've done debug ip packet detail on access list caching returning ip and icmp traffic. Here's the extract:
*Oct 29 15:05:19.244: IP: s=192.168.0.6 (FastEthernet0/1), d=172.16.120.1, len 60, input feature
*Oct 29 15:05:19.244: ICMP type=0, code=0, Stateful Inspection(4), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 29 15:05:19.244: IP: s=192.168.0.6 (FastEthernet0/1), d=172.16.120.1, len 60, input feature
*Oct 29 15:05:19.244: ICMP type=0, code=0, Virtual Fragment Reassembly(18), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 29 15:05:19.244: IP: s=192.168.0.6 (FastEthernet0/1), d=172.16.120.1, len 60, input feature
*Oct 29 15:05:19.244: ICMP type=0, code=0, Virtual Fragment Reassembly After IPSec Decryption(29), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 29 15:05:19.244: IP: s=192.168.0.6 (FastEthernet0/1), d=172.16.120.1, len 60, input feature
*Oct 29 15:05:19.244: ICMP type=0, code=0, MCI Check(59), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 29 15:05:19.244: FIBipv4-packet-proc: route packet from FastEthernet0/1 src 192.168.0.6 dst 172.16.120.1
*Oct 29 15:05:19.244: FIBfwd-proc: Default:172.16.120.1/32 proces level forwarding
*Oct 29 15:05:19.248: FIBfwd-proc: depth 0 first_idx 0 paths 1 long 0(0)
*Oct 29 15:05:19.248: FIBfwd-proc: try path 0 (of 1) v4-ah-172.16.120.1-Vi6 first short ext 0(-1)
*Oct 29 15:05:19.248: FIBfwd-proc: v4-ah-172.16.120.1-Vi6 valid
*Oct 29 15:05:19.248: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Virtual-Access6 nh 172.16.120.1 deag 0 via fib 0 path type attached host
*Oct 29 15:05:19.248: FIBfwd-proc: packet routed to Virtual-Access6 172.16.120.1(0)
*Oct 29 15:05:19.248: FIBipv4-packet-proc: packet routing succeeded
*Oct 29 15:05:19.248: FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Virtual-Access6 nh 172.16.120.1 uhp 1 deag 0 ttlexp 0
*Oct 29 15:05:19.248: FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if Virtual-Access6 nh 172.16.120.1 uhp 1 deag 0 ttlexp 0 rec 0
*Oct 29 15:05:19.248: IP: s=192.168.0.6 (FastEthernet0/1), d=172.16.120.1 (Virtual-Access6), len 60, output feature
*Oct 29 15:05:19.248: ICMP type=0, code=0, CCE Post NAT Classification(29), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Oct 29 15:05:19.248: IP: s=192.168.0.6 (FastEthernet0/1), d=172.16.120.1 (Virtual-Access6), len 60, output feature
192.168.0.6 is an ip phone in local lan, 172.16.120.6 is virtual access pptp client address. looks like the routing is done correctly, but no ping replies are seen on pc.
there's a zone-based fw, but all interfaces in question (lan & vir.tunnels) are in the same zone.
the RA config was cloned from my other environment where it works fine.
what could cause that? I even made a counter ACL on pptp vir-templ out and it catches both icmp and http returning packets! of course, no windows or 3rd party firewall enabled on pc, checked on multiple pcs and checked benchamrk system from my pc and it's ok there.
thanks in advance.
11-23-2009 06:22 PM
i have a somewhat similar solution and had to enable ip proxy-arp on the fast ethernet interface for the lan segment in question...you might give that a shot if you haven't already found your solution...
11-23-2009 11:56 PM
I think I've found the solution myself - it turned out to be a nasty IOS bug related to zone-based firewall. Even placing both virtual template and lan interfaces in the same zone didn't make the traffic pass, bud removing all zones did the job. So I downgraded the box to 12.4(15)T something (7 as far as I remember) and there is no such issue there. Actually I'm rather tired of having to come across such stupid software bugs...
But now it has some other funny things. For instance, VPN client connection is successful in 50% attempts. So you just have to connect twice in most cases (though in terms of PCs and Internet connectivity nothing has changed). Another piece of fun is that after downgrading half of ephones were gone from configuration file and many lost button assignments =)
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