--- USING.orig Sat Nov 4 15:37:29 2006 +++ USING Thu Nov 9 14:17:25 2006 @@ -1,5 +1,10 @@ Usage Notes +[ Note by your friendly OpenBSD pptp port maintainer: +Most examples in this file are quite Linux-centric. See the section +EXAMPLE CONFIGURATION FOR OPENBSD below for an example that focuses +on OpenBSD exclusively. ] + pptp is started as a psuedo-tty child process using pppd's pty option: pppd call provider [pppd-options] \ @@ -94,5 +99,96 @@ test-multiple-tunnels-1.sh creates multiple source interfaces test-multiple-tunnels-2.sh creates multiple tunnels + + +EXAMPLE CONFIGURATION FOR OPENBSD: + +On OpenBSD, pptp uses the userspace ppp(8) implementation +by default, instead of using pppd(8). This is a compile-time option +hardcoded in the port's Makefile, and it is not recommended that you +change this unless you really have a reason to do so. If your VPN +requires mppe/mppc in conjunction with pptp, ppp(8) is your +only option anyway since pppd(8) does not support mppe/mppc. + +This example assumes that you want to configure a gateway running +OpenBSD to provide PPTP VPN access to a remote network for all hosts +on your internal LAN. While this may not match your situation at +all, you will hopefully gather enough hints you can use for your +own setup. + +Let us assume that the VPN server is called vpn-gateway.net, +and that the default route of our OpenBSD box is 42.42.42.42. +The remote network is 10.42.0/16; all traffic to this network +should go through the VPN tunnel. + +Having ppp start pptp seems to be working much better than the +other way round. So first, put something like this into /etc/ppp/ppp.conf +to connect to the vpn gateway: + + default: + set log Phase Chat LCP IPCP CCP tun command + vpn: + set device "!PREFIX/sbin/pptp --nolaunchpppd vpn-gateway.net" + set authname User + set authkey MySecret + set mppe 128 stateless + +Next, you need to configure routing in /etc/ppp/ppp.linkup. +Assuming vpn-gateway.net resides inside 10.42.0/16, we have to add a host +route pointing to vpn-gateway.net in order to avoid a chicken-and-egg +problem once packets to 10.42.0/16 are routed through the tunnel. +(Of course, this also applies if you need to configure the tunnel as +your default route, but that is not covered in this example.) + +We also load packet filter anchors for the vpn interface here. +More on that later. + +/etc/ppp/ppp.linkup: + + vpn: + ! sh -c "/sbin/route add -host vpn-gateway.net 42.42.42.42" + ! sh -c "/sbin/route add -net 10.42.0.0 -netmask 255.255.0.0 HISADDR" + ! sh -c "/sbin/pfctl -a vpn -f /etc/pf.conf.vpn" + +Commands in ppp.linkdown simply undo changes made in ppp.linkup. + +/etc/ppp/ppp.linkdown: + + vpn: + ! sh -c "/sbin/pfctl -a vpn -F all" + ! sh -c "/sbin/route delete -net 10.42.0.0 -netmask 255.255.0.0 HISADDR" + ! sh -c "/sbin/route delete -host vpn-gateway.net 42.42.42.42" + +To make pf aware of the vpn anchors, put these lines into the +nat and filter sections of /etc/pf.conf, respectively: + + nat-anchor vpn + anchor vpn + +Now define vpn anchor rules in /etc/pf.conf.vpn: + + int_if=xl0 + vpn_if=tun0 + + nat on $vpn_if from $int_if:network to any -> ($vpn_if) + + pass out on $vpn_if keep state + + # Allow ping from remote, and explicitly make sure our replies are + # routed back through the tunnel. + pass in on $vpn_if reply-to ($vpn_if vpn-gateway.net) \ + inet proto icmp icmp-type echoreq keep state + + # Same for ssh. + pass in on $vpn_if reply-to ($vpn_if vpn-gateway.net) proto tcp \ + from any to ($vpn_if) port ssh flags S/SA keep state + + +Connect by running: + + ppp -ddial vpn + +To terminate the connection, kill the ppp process. It creates a PID +file in /var/run/tunX.pid, where X is the number of the tun device used. $Id: patch-USING,v 1.2 2006/11/12 10:10:09 grunk Exp $