>Number:         25344
>Category:       kern
>Synopsis:       ppp proxyarp problem
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 27 09:01:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Roberto Trovo
>Release:        NetBSD 1.6.2
>Organization:
>Environment:
NetBSD netbsd.redix.it 1.6.2 NetBSD 1.6.2 (MYKERNEL-162-20040414) #0: Wed Apr 14 18:46:35 CEST 2004     root@netbsd.redix.it:/usr/src/sys/arch/i386/compile/MYKERNEL-162-20040414 i386

>Description:
####################################################
##
## Please assigne the bug to cube (cube@cubidou.net)
##
####################################################

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?



>How-To-Repeat:
On NetBSD 162, try to configure a ppp server with the option proxyarp enabled;
>Fix:
Manually adjust the arp cache and the routing entry (or for ex. using ip-up script);
>Release-Note:
>Audit-Trail:
>Unformatted: