Hi.
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 -> 10.2.0.1 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: 1.0.0.2. The openvpn daemon is listening on 10.2.0.1, 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 > 10.0.0.2.11940: UDP, length 54 pflog0: 00:00:16.820380 rule 0..16777216/0(match): pass in on fxp0: x.x.x.x.11940 > 10.2.0.1.11940: UDP, length 54 So, packets come in fxp0 from x.x.x.x and then after the rdr rule, they're sent to 1.2.0.1:11940. 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 example.com 11940 Connection to example.com 11940 port [udp/*] succeeded! The openvpn server log then shows a TLS handshake error (as expected, as nc obviously isn't performing a TLS handshake). 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? _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
