Hi Folks,
I setup my PPTP VPN Server on FreeBSD using the configuration on this thread:
For the first time, I tried connecting to my server from an iPod Touch.
But it refuses to connect. When I saw the logs, I got:
Then I found this http://poptop.sourceforge.net/dox/qna.html:
As it suggests I created /etc/ppp/ip-up and /etc/ppp/ip-down. Even /etc/ppp/ip-down.local and /etc/ppp/ip-up.local. But there is no luck.
I setup my PPTP VPN Server on FreeBSD using the configuration on this thread:
Code:
http://forums.freebsd.org/showthread.php?t=15313
For the first time, I tried connecting to my server from an iPod Touch.
But it refuses to connect. When I saw the logs, I got:
Code:
$ tail -f /var/log/messages
Apr 11 17:19:58 t5r9 kernel: tun1: link state changed to UP
Apr 11 17:20:05 t5r9 pptpd[26231]: CTRL: EOF or bad error reading ctrl packet length.
Apr 11 17:20:05 t5r9 pptpd[26231]: CTRL: couldn't read packet header (exit)
Apr 11 17:20:05 t5r9 pptpd[26231]: CTRL: CTRL read failed
Apr 11 17:20:05 t5r9 ppp[26232]: tun1: Warning: 192.168.1.230: Cannot determine ethernet address for proxy ARP
Apr 11 17:20:05 t5r9 kernel: tun1: link state changed to DOWN
Then I found this http://poptop.sourceforge.net/dox/qna.html:
Code:
Cannot determine ethernet address for proxy ARP
This is due to an issue with the pppd program, which attempts to find a hardware interface on
the subnet to which the pppd client has been assigned. In this case its looking for a hardware
interface on the 192.168.5.0 subnet. It will fail to find one, and will drop the proxyarp
request.
The simplest way around this problem, and the one that is suggested in the pppd documentation,
is to set the pppd client IP assignment to be on the local subnet. An example in this case might
be 192.168.56.129. However, it may not be possible to do that. In the case of a fully loaded
subnet, there may not be any addresses to spare. Or there may be some security issues with
giving out local subnet addresses. What to do?
The place to look is in the arp table. If you run tcpdump on host (192.168.56.12) during the
time when client is pinging, you will see unanswered arp requests from host attempting to find
the hardware address for 192.168.5.12. You need to proxy the hardware address of the pptp_srvr
for client in order for this request to be fulfilled. This is the job of proxyarp. However,
proxyarp has let us down in this instance, and we need to find a workaround.
This can be done manually using the arp command on pptp_srvr. For example, if the ethernet card
on pptp_srvr is eth0, you could force the arp to proxy the client pptp address by saying
arp --use-device --set 192.168.5.12 eth0 pub
You should now be able to ping from client to host through the pptp connection.
This can be a problem, however, in a dynamic environment when clients are logging into and out
of the pptp server on a continuous basis. One way around this problem is to write a script that
will execute upon the initiation of each ppp connection.
The place to do this is in /etc/ppp/ip-up. This script is executed each time a new ppp
connection is started. It gets some variables passed into it, one of which is the assigned IP
address of the client. Note that Red Hat systems use ip-up.local as the place for you to make
the script. Don't forget to chmod +x !
#!/bin/sh
REMOTE_IP_ADDRESS=$5
date > /var/run/ppp-${REMOTE_IP_ADDRESS}.up
arp --use-device --set $REMOTE_IP_ADDRESS eth0 pub >> /var/run/ppp-${REMOTE_IP_ADDRESS}.up
exit 0
This should put you in business for accessing the remote subnet under this scenario. A
corresponding ip-down.local script, that will remove the arp proxy when client disconnected,
looks as follows:
#!/bin/sh
REMOTE_IP_ADDRESS=$5
arp --delete $REMOTE_IP_ADDRESS --device eth0 pub
rm -f /var/run/ppp-${REMOTE_IP_ADDRESS}.up
exit 0
As it suggests I created /etc/ppp/ip-up and /etc/ppp/ip-down. Even /etc/ppp/ip-down.local and /etc/ppp/ip-up.local. But there is no luck.