> ...
> FWIW, I have an ip-up script to add the correct route on my setup here.  I
> admit I've never looked at this closely, and as long as my puny windows
> users
> don't give me too much gas (which means that It Works), I'm happy.
>
> It might be worth filling a PR.  Assign it to 'cube', so I can remember to
> have a look at it when I have more time.  Meanwhile, the ip-up trick
> should
> do.
>
> Quentin Garnier.
>

On 27 apr, I submitted a PR as suggested:
   kern/25344: ppp proxyarp problem



In the meantime, during some tests on the VPN I discover the following:

 1) setting the ppp option "netmask 255.255.255.255" seems to fix the
proxyapr problem; now the route are (*.80 is the local ppp endpoint, *.81
is the remote endpoint):
...
192.168.0.81       192.168.0.80       UH       0        1      -  ppp0
192.168.0.81       00:40:63:c9:cb:ec  UHLS2    0        0      -  vr0

(actuall I do not understand the route for 192.168.0.81 to vr0 ! )

and arp:
? (192.168.0.81) at 00:40:63:c9:cb:ec on vr0 permanent published(proxy only)

so now arp do not shows a duplicate entry like: (192.168.0.82) at
(incomplete) on vr0;

I'll submit a more detailed route monitor to PR.



2) rcv [Compressed data] xx xx xx xx xx problem
During my test, randomly the VPN link stop transmitting & receiving any
data: after a web search I've discovered there is a patch for mppe.o
kernel module that it is not included in the ppp-mppe package (binary &
source) for netbsd 162.
After apply the patch the problem seems disappared (it is under testing yet).
(the url is: http://www.vibrationresearch.com/pptpd/ )

Anybody using PPTP and MPPE did discover the problem? Is the patch already
 known ?


3) testing the PPTP VPN on a 100Mbit LAN the max download speed is only
100 KByte;
Are there any reason the speed is so slow?

Regards
Roberto Trovo'