Subject: Re: PPTP VPN problem
To: Johnnie Chen <iwchen@l7.com.tw>
From: None <roberto.trovo@redix.it>
List: tech-net
Date: 04/22/2004 15:17:31
Johnnie Chen Wrote:
> Hi, I can successfully setup PPTP tunnel, and here is my routing talbe
> entries:
>
> .............
> 192.168.166.70     192.168.166.254    UH          0       25   1400  ppp0
> 192.168.166.70     00:0d:88:17:0b:9a  UHLS2       0        0   1500  rtk1
> ......................
>
> Hope this can help you.
> By the way, what's the version of pppd you use ?
> My pppd (2.3.9) can NOT support MPPE unless using kernel module (mppe.o).
> Is your MPPE also supported by kernel module ?
>
> --
> Johnnie
>

On NetBSD 162, I've tried with:
 pppd version 2.4.0 (dafault, no mppe)
 pppd version 2.3.9  (mppe,mschap enabled)

but the result is the same!
Here is a detailed test description:
			|
	Internal LAN	|	External Net
			|
			|
LAN	<----->	VPN Gateway (PPTP) <----> Remote VPN Client (PPTP)

        (rtk0)192.168.0.80   (vr0)10.1.1.1	  10.1.1.10(fictitious)


external lan: 10.1.1.1(rtk0)	external client: 10.1.1.10
internal lan: 192.168.0.80 (vr0)

pptp IP setup: 192.168.0.80 – 192.168.0.82-99

bambolotto:/root> cat  /etc/ppp/options.nomppe
debug
passive
auth
+pap
+chap
proxyarp
ms-dns 192.168.0.1

bambolotto:/root> cat  /etc/ppp/pptpd.conf
localip 192.168.0.80
remoteip 192.168.0.82-99


Test: Now the client connet to the VPN server: the VPN tunnel is
client-192.168.0.82 and  server-192.168.0.80.

Take a look at routing & ifconfig:
bambolotto:/root> netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu 
Interface
xx.xx.xx.xx/29     link#2             UC          1        0      -  rtk0
xx.xx.xx.xx        00:06:1b:d9:83:3f  UHLc        3     1603      -  rtk0
127                127.0.0.1          UGRS        0        0  33220  lo0
127.0.0.1          127.0.0.1          UH          1       72  33220  lo0
192.168            link#1             UC          2        0      -  vr0
192.168.0.1        00:a0:a2:00:25:69  UHLc        1       11      -  vr0
192.168.0.82       link#1             UHLc        0        1      -  vr0
192.168.0.82       00:40:63:c9:cb:ec  UHLS2       0        0      -  vr0

bambolotto:/root> ifconfig -a
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:40:63:c9:cb:ec
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 192.168.0.80 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 fe80::240:63ff:fec9:cbec%vr0 prefixlen 64 scopeid 0x1
rtk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:06:7b:08:34:69
        media: Ethernet autoselect (none)
        status: active
        inet xx.xx.xx.xx netmask 0xfffffff8 broadcast xx.xx.xx.xx
        inet6 fe80::206:7bff:fe08:3469%rtk0 prefixlen 64 scopeid 0x2
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33220
        inet 127.0.0.1 netmask 0xff000000
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet6 ::1 prefixlen 128
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1400
        inet 192.168.0.80 -> 192.168.0.82 netmask 0xffffff00
        inet6 fe80::240:63ff:fec9:cbec%ppp0 -> :: prefixlen 64 scopeid 0x4
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
strip0: flags=0<> mtu 1100
strip1: flags=0<> mtu 1100

Pinging from remote VPN client to the LAN host 192.168.0.75 the result is
a ping timeout: on the server, tcpdump says only the request is passed on
the LAN but no reply is tunneled back: instead a icmp redirect is
generated.

bambolotto:/root> tcpdump -i vr0 -e
tcpdump: listening on vr0

14:55:56.026953 0:40:63:c9:cb:ec Broadcast arp 60: arp who-has
192.168.0.75 tell 192.168.0.80
14:55:56.027634 0:40:33:33:d6:b4 0:40:63:c9:cb:ec arp 64: arp reply
192.168.0.75 is-at 0:40:33:33:d6:b4
14:55:56.027661 0:40:63:c9:cb:ec 0:40:33:33:d6:b4 ip 74: 192.168.0.82 >
192.168.0.75: icmp: echo request
14:55:56.028843 0:40:33:33:d6:b4 Broadcast arp 64: arp who-has
192.168.0.82 tell 192.168.0.75
14:55:56.028866 0:40:63:c9:cb:ec 0:40:33:33:d6:b4 arp 60: arp reply
192.168.0.82 is-at 0:40:63:c9:cb:ec
14:55:56.029380 0:40:33:33:d6:b4 0:40:63:c9:cb:ec ip 78: 192.168.0.75 >
192.168.0.82: icmp: echo reply
14:55:56.029411 0:40:63:c9:cb:ec Broadcast arp 60: arp who-has
192.168.0.82 tell 192.168.0.80
14:55:56.029453 0:40:63:c9:cb:ec 0:40:33:33:d6:b4 ip 70: 192.168.0.80 >
192.168.0.75: icmp: redirect 192.168.0.82 to host 192.168.0.82

The arp table is:
bambolotto:/root> arp -a
? (xx.xx.xx.xx) at 00:06:1b:d9:83:3f on rtk0
? (192.168.0.1) at 00:a0:a2:00:25:69 on vr0
? (192.168.0.82) at (incomplete) on vr0
? (192.168.0.82) at 00:40:63:c9:cb:ec on vr0 permanent published (proxy only)
bambolotto:/root>

My question are:
1) what are the meanings of the routing and its flags UHLc and UHLS2?:
192.168.0.82       link#1             UHLc        0        1      -  vr0
192.168.0.82       00:40:63:c9:cb:ec  UHLS2       0        0      -  vr0

2) why your proxyarp option setup a route (different for mine)?:
> 192.168.166.70     192.168.166.254    UH          0       25   1400  ppp0
> 192.168.166.70     00:0d:88:17:0b:9a  UHLS2       0        0   1500  rtk1
(look at interface ppp0 and not vr0!)

1) why the pptp server do not tunnel the echo reply?


Regards
Roberto Trovo'