Date: Sun, 8 Jul 2012 13:25:37 +0100 (BST) From: Jeff Hedges <jeffhedges79@yahoo.com> To: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Working openvpn/pf configuration broken on upgrade from 8.3 to 9.0 Message-ID: <1341750337.36593.YahooMailNeo@web171204.mail.ir2.yahoo.com>
next in thread | raw e-mail | index | archive | help
=0A=0AHi.=0A=0AI'm running a small VPN for ~10 office users. Upon upgrading= the machine from 8.3 to 9.0 yesterday, it became=0Aimpossible for users to= connect to the VPN. I've tried everything I can think of to track down the= problem and it=0Aseems (although I may be mistaken) to be something to do = with pf and a redirect rule. Here is the pf.conf on=0Athe machine:=0A=0A--%= <--=0A=0Anic_wan =3D fxp0=0Anic_dmz =3D fxp2=0Anic_tun =3D tun0 =0A# Perfor= m NAT for outgoing connections from the DMZ=0Anat log on $nic_wan from $nic= _dmz:network to any -> ($nic_wan)=0A=0A# Redirect incoming openvpn clients = from the WAN to the openvpn server=0Ardr log on $nic_wan proto udp from any= to any port 11940 -> 10.2.0.1 port 11940=0A=0Apass log all=0A=0A--%<--=0A= =0AThe fxp0 interface is connected directly so a small DSL modem that simpl= y forwards everything=0Ato this machine (no NAT, no filtering, etc). The fx= p0 has one address: 1.0.0.2.=0A=0AThe openvpn daemon is listening on 10.2.0= .1, which is the only IP bound to the fxp2 interface.=0A=0AHere is where th= e madness starts:=0A=0ARunning tcpdump on fxp0 and pflog0 shows the followi= ng when a remote user x.x.x.x connects:=0A=0Afxp0: 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.11= 940: UDP, length 54=0Apflog0: 00:00:16.820380 rule 0..16777216/0(match): pa= ss in on fxp0: x.x.x.x.11940 > 10.2.0.1.11940: UDP, length 54 =0ASo, packet= s come in fxp0 from x.x.x.x and then after the rdr rule, they're sent to 1.= 2.0.1:11940.=0A=0AHowever, the openvpn server log shows nothing, even at th= e highest verbosity settings. The connecting=0Aclient eventually receives a= "handshake timed out" message and either gives up or tries again.=0A=0AUsi= ng nc, it's possible to see that packets *are* getting through:=0A=0A$ nc -= u -vvv example.com 11940=0AConnection to example.com 11940 port [udp/*] suc= ceeded!=0A=0AThe openvpn server log then shows a TLS handshake error (as ex= pected, as nc obviously isn't performing a TLS=0Ahandshake).=0A=0AIf I, fro= m inside the DMZ, try to connect an openvpn client to the server, the conne= ction immediately=0Asucceeds and everything works correctly. Therefore, I b= elieve that the 'rdr' rule in the pf.conf=0Ais probably to blame and that s= omething pretty fundamental has changed between 8.3 and 9.0. From=0Athe biz= arre behaviour (letting packets through but apparently "damaged" in some wa= y), I'm guessing=0Athat this is a bug.=0A=0ADoes anyone have any idea how I= can track down what's going on?=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1341750337.36593.YahooMailNeo>