Working openvpn/pf configuration broken on upgrade from 8.3 to 9.0

Jeff Hedges jeffhedges79 at
Sun Jul 8 12:25:45 UTC 2012


I'm running a small VPN for ~10 office users. Upon upgrading the machine from 8.3 to 9.0 yesterday, it became
impossible for users to connect to the VPN. I've tried everything I can think of to track down the problem and it
seems (although I may be mistaken) to be something to do with pf and a redirect rule. Here is the pf.conf on
the machine:


nic_wan = fxp0
nic_dmz = fxp2
nic_tun = tun0 
# Perform NAT for outgoing connections from the DMZ
nat log on $nic_wan from $nic_dmz:network to any -> ($nic_wan)

# Redirect incoming openvpn clients from the WAN to the openvpn server
rdr log on $nic_wan proto udp from any to any port 11940 -> port 11940

pass log all


The fxp0 interface is connected directly so a small DSL modem that simply forwards everything
to this machine (no NAT, no filtering, etc). The fxp0 has one address:

The openvpn daemon is listening on, which is the only IP bound to the fxp2 interface.

Here is where the madness starts:

Running tcpdump on fxp0 and pflog0 shows the following when a remote user x.x.x.x connects:

fxp0: 00:00:00.443090 00:50:7f:21:67:94 > 00:d0:b7:40:4b:31, IPv4, length 96: x.x.x.x.11940 > UDP, length 54
pflog0: 00:00:16.820380 rule 0..16777216/0(match): pass in on fxp0: x.x.x.x.11940 > UDP, length 54 
So, packets come in fxp0 from x.x.x.x and then after the rdr rule, they're sent to

However, the openvpn server log shows nothing, even at the highest verbosity settings. The connecting
client eventually receives a "handshake timed out" message and either gives up or tries again.

Using nc, it's possible to see that packets *are* getting through:

$ nc -u -vvv 11940
Connection to 11940 port [udp/*] succeeded!

The openvpn server log then shows a TLS handshake error (as expected, as nc obviously isn't performing a TLS

If I, from inside the DMZ, try to connect an openvpn client to the server, the connection immediately
succeeds and everything works correctly. Therefore, I believe that the 'rdr' rule in the pf.conf
is probably to blame and that something pretty fundamental has changed between 8.3 and 9.0. From
the bizarre behaviour (letting packets through but apparently "damaged" in some way), I'm guessing
that this is a bug.

Does anyone have any idea how I can track down what's going on?

More information about the freebsd-questions mailing list