ipsec & pptp remote access routing problem

v_bashaev · ‎10-29-2009

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.

brian.hooper · ‎11-23-2009

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...

v_bashaev · ‎11-23-2009

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 =)