I’m configuring an OpenVPN gateway to allow a LAN access to the internet through the tunnel. The gateway is running OpenBSD 5.5-stable amd64 on the PC Engines APU platform.
The LAN contains re1, re2, and ral0 interfaces. It also contains vether0 which hosts the local 192.168.2.0/24 network. These interfaces are linked under bridge0 to provide a common gateway, subnet, and DHCP via dhcpd.
The VPN is established and tun0 is opened. The gateway itself can access the VPN just fine.
The problem is that, by default, the hosts access the VPN with their native 192.168.2.0/24 addresses. NAT is needed to translate the local network to the VPN network at 10.0.1.0/24.
I have tried the following pf.conf configurations:
# pf.conf -- 10.0.1.10 is my tun0 gateway
set skip on lo
block return
pass in quick on { vether0 re1 re2 ral0 } from 192.168.2.0/24 to !10.0.0.0/8 nat-to 10.0.1.10
pass
I had similar results with these rules:
# pf.conf
...
pass in from any nat-to 10.0.1.10
pass out from tun0 to any
This allows LAN traffic to pass through tun0 with a source address of 10.0.1.10, and return traffic is passed back to the respective host. The new problem is that return traffic still does not appear to be routing correctly.
For example, I can ping 8.8.8.8 and google.com from any LAN host, however the first reply is ALWAYS dropped between tun0 and the return interface. Tools like dig, nslookup, traceroute, and ping are generally sluggish and take far longer than they should. Despite some traffic still passing, browsers and other applications are unusable.
tcpdump demonstrating the loss:
# 192.168.2.103 is a LAN host
# 74.125.131.139 is google.com
# on ral0
20:59:35.668251 192.168.2.103 > 74.125.131.139: icmp: echo request <-- no reply
20:59:40.651184 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:40.736748 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:41.656101 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:41.741251 74.125.131.139 > 192.168.2.103: icmp: echo reply
20:59:42.661071 192.168.2.103 > 74.125.131.139: icmp: echo request
20:59:42.802410 74.125.131.139 > 192.168.2.103: icmp: echo reply
# on tun0
20:59:35.668359 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:35.764052 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- here's the missing reply, it didn't get to ral0
20:59:40.651221 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:40.736721 74.125.131.139 > 10.0.1.10: icmp: echo reply <-- but the of the replies rest did
20:59:41.656138 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:41.741226 74.125.131.139 > 10.0.1.10: icmp: echo reply
20:59:42.661107 10.0.1.10 > 74.125.131.139: icmp: echo request
20:59:42.802372 74.125.131.139 > 10.0.1.10: icmp: echo reply
I know that this is almost certainly a NAT issue in pf.conf but after so many configuration attempts I’m having trouble finding the correct way to go about passing traffic.
When I was using DD-WRT and iptables, this was my configuration:
iptables -D FORWARD -i tun1 -j logaccept
iptables -D FORWARD -o tun1 -j logaccept
I’m not sure how to “port” this to pf, though. Any suggestions would be greatly appreciated!