Hi all,
Summary,
Trying to run pptp client on my router and allow my internal Lan clients to
be natted through the tunnel. NAT appears to never happen from what I can
tell I've got everything configured correctly, though I've never set this up
before.
Thanks in advance for your help. I've tried to be as verbose as possible
with including all the files being uses in relation to this issue, if more
info is needed just say so.
Thanks,
J
I'm trying to get a pptp client on my router to function as described here
in the pptp man page.
*PPTP on a router
This example assumes that you want to configure a router running
OpenBSD
to provide PPTP VPN access to a remote network for all hosts on your
in-
ternal network.
Let us assume that the VPN server was called vpn-gateway.net, and that
the default route of our OpenBSD box was 42.42.42.42. The remote
network
shall be 10.42.0.0/16; we want all traffic to this network to go
through
the VPN tunnel.
First, edit /etc/ppp/ppp.conf and add an entry for the VPN connection.
See ppp(8) for details on the format of this file.
default:
set log Phase Chat LCP IPCP CCP tun command
vpn:
set device "!/usr/local/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. We also
load
pf(4) anchors for the vpn interface here. More on that later.
/etc/ppp/ppp.linkup:
vpn:
add 10.42.0.0/16 HISADDR
! sh -c "/sbin/pfctl -a vpn -f /etc/pf.conf.vpn"
If vpn-gateway.net resides inside 10.42.0.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.0/16 are routed through the tunnel.
/etc/ppp/ppp.linkup:
vpn:
add vpn-gateway.net 42.42.42.42
add 10.42.0.0/16 HISADDR
! sh -c "/sbin/pfctl -a vpn -f /etc/pf.conf.vpn"
If your default route is not fixed, for example if your ISP does not
al-
ways assign the same gateway to you, use a script to figure out the
cur-
rent default route and add the host route to the VPN gateway. For
exam-
ple:
/etc/ppp/vpn-default-route.sh:
#!/bin/sh
gw=`netstat -rn -f inet | grep ^default | awk '{print $2};'`
/sbin/route add -host vpn-gateway.net ${gw}
Call the script from /etc/ppp/ppp.linkup:
vpn:
! sh /etc/ppp/vpn-default-route.sh
add 10.42.0.0/16 HISADDR
! sh -c "/sbin/pfctl -a vpn -f /etc/pf.conf.vpn"
Make sure the changes to the routing table are
reversed when the VPN connection drops:
/etc/ppp/ppp.linkdown:
vpn:
! sh -c "/sbin/pfctl -a vpn -F all"
delete 10.42.0.0/16
delete vpn-gateway.net
# NAT is of course optional. The remote network needs
# a route to our network as well if we don't do NAT.
nat on $vpn_if from $int_if:network to any -> ($vpn_if)
block drop on $vpn_if
pass out on $vpn_if
# 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 -unit0 -ddial vpn
The -unit0 option makes sure ppp configures tun0 as the VPN connection
end point, and not some other tun device. The packet filter rules con-
figured above assume tun0 as the VPN connection end point.
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.*
I have tried to match this as much as possible on my setup, but I can't seem
to get the packets from the LAN network to NAT to the pptp ip address, here
are my files that I'm actually using:
*pf.conf:*
##############
### Tables ###
##############
table <abusive_hosts> persist
###############
### Aliases ###
###############
RFC_1918 = "{ 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"
LAN_IP = "192.168.254.1"
LAN_Network = "192.168.254.0/24"
#########################
### Global PF Options ###
#########################
set skip on lo0
set loginterface dc0
#############################
### Traffic Normalization ###
#############################
scrub in all fragment reassemble
#################
### RDR rules ###
#################
rdr-anchor "ftp-proxy/*"
rdr-anchor "relayd/*"
###################
### FWall-MGMT ###
###################
rdr on dc0 proto tcp \
from { any } to { 192.168.185.52 }\
port{ 443 } -> 192.168.254.1
###############
### FTP-OUT ###
###############
rdr on dc1 proto tcp \
from { any } to { any }\
port{ 21 } -> 127.0.0.1 port 8021
#################
### NAT rules ###
#################
nat-anchor "ftp-proxy/*"
nat-anchor "vpn/*"
nat on dc0 from 192.168.254.0/24 to any -> (dc0)
#######################
#### Default Policy ###
#######################
anchor "default" {
block in log all
pass out all
}
#######################################################
#### Activate spoofing protection on all interfaces ###
#######################################################
block in quick from urpf-failed
############################################
### Allow our DHCP client out to the WAN ###
############################################
pass out quick on dc0 proto udp from any port 68 to any port 67
block in log quick on dc0 proto udp from any port 67 to
192.168.254.0/24 port 68
pass in quick on dc0 proto udp from any port 67 to any port 68
###########################
### LAN/OPT spoof check ###
###########################
anchor "spoofed-source" {
block in log quick on dc1 from ! 192.168.254.0/24 to any
}
###########################
### WebGUI anti-lockout ###
###########################
pass in quick on dc1 proto tcp from 192.168.254.0/24 to 192.168.254.1 \
port { 443 }
##############################
##############################
##### User Defined Rules #####
##############################
##############################
############
### SNMP ###
############
anchor "SNMP" {
pass in quick on dc0 inet proto tcp \
from { any } to { any } \
port { 161 }
}
###################
### FWall-MGMT ###
###################
anchor "NSWall-MGMT" {
pass in log quick on dc0 inet proto tcp \
from { any } to { 192.168.254.1 } \
port { 443 }
}
###################
### Default-Out ###
###################
anchor "Default-Out" {
pass in log quick on dc1 inet from { any } to { any }
}
###############
### FTP-OUT ###
###############
anchor "FTP-OUT" {
pass in log quick on dc1 inet proto tcp \
from { any } to { 127.0.0.1 } \
port { 8021 } keep state
}
##########################
##### System Anchors #####
##########################
anchor "ftp-proxy/*"
anchor "vpn/*"
*/etc/ppp/ppp.conf:*
$ cat /etc/ppp/ppp.conf
default:
set log Phase Chat IPCP CCP tun command LCP
vpn:
set device "!/sbin/pptp --nolaunchpppd vpn.myserver.com"
set authname testz1
set authkey asdfasdf
set mppe 128 stateless
disable ipv6
*/etc/ppp/ppp.linkup:*
$ cat /etc/ppp/ppp.linkup
vpn:
! sh -c "/sbin/pfctl -a pptp_client -f /etc/ppp/pf.conf.vpn"
add vpn.myserver.com 192.168.185.1
add xxx.xxx.xxx.0/24 HISADDR
*/etc/ppp/ppp.linkdown:*
$ cat /etc/ppp/ppp.linkdown
vpn:
! sh -c "/sbin/pfctl -a vpn -F all"
delete vpn.myserver.com
delete xxx.xxx.xxx.0/24
*/etc/ppp/pf.conf.vpn:*
$ cat /etc/ppp/pf.conf.vpn
vpn_if=tun0
secure_if=dc1
# NAT is of course optional. The remote network needs
# a route to our network as well if we don't do NAT.
nat on $vpn_if from $secure_if:network to any -> ($vpn_if)
block drop on $vpn_if
pass out on $vpn_if
pass in on $vpn_if reply-to ($vpn_if vpn.myserver.com) \
inet proto icmp icmp-type echoreq keep state
# Same for ssh.
pass in on $vpn_if reply-to ($vpn_if vpn.myserver.com) proto tcp \
from any to ($vpn_if) port ssh flags S/SA keep state
Now, whats interesting, is that I can ping from the router itself to a
host on the other end of the tunnel, so I know that the tunnel is
established.
However when I attempt to ping from a host on the LAN segment, the NAT
action never takes place in the /etc/ppp/pf.conf.vpn The source
address stays the same I can see this via a tcpdump on the tun0
interface.
Even though a pfctl -a vpn -s nat shows this:
$ pfctl -a vpn -s nat
nat on tun0 inet from 192.168.254.0/24 to any -> (tun0) round-robin
I'm pretty much at a loss as to why the nat rule is not taking place,
if anyone out there can shed any light onto what I'm missing I thank
you in advance, this one has been going on for a long time and I'm
really needing to figure out what I'm missing here ASAP
Jim
