Regression from 2.2 to 2.3 beta, tap related bugs/workarounds.

[hcoin]

Several openvpn bugs with workarounds are described below, found in the course of getting openvpn server 2.2.0 on Freebsd 8 (pfsense release 2.0.1) TAP connections to windows 'road warrior' clients.

For full details and context see:

​http://forum.pfsense.org/index.php/topic,54701.msg292497.html#msg292497

The openvpn bugs with workarounds follow:

Item 1: Half bug, half feature request: There needs to be a way to remove the route to openvpn tunnels after openvpn server has been configured but isn't running / active. Reason: Hot standby servers can't be accessed from the distant side of openvpn tunnels as the return packet route on the not-running server nevertheless routes the return packets (destination: tunnel subnet to the local, and on the standby server disconnected, openvpn tunnel interface. The packets just disappear without log or trace. Workaround is to snat the outgoing packets to the backup server sourced from the tunnel. It's a hack, but it will do until the openvpn removes routes not actually connected from the routing table.

Item 2, Regression from 2.2.0 to 2.3 BETA: When using the native lan DHCP server + openvpn server in tap mode: The 2.3 beta won't pass a windows laptop client's link/MAC address over the TAP vpn to the 'home office' dhcp server, so you won't get the correct static IP configured on PFsense's DHCP LAN server page. Using 2.2 laptops using openvpn get the correct IP address associated with their MAC, using 2.3 BETA their MAC is lost and the remote clients get addresses from the reserved pool, not the static ones predefined. (Or, they get rejected and not served any address in security related settings with no general DHCP unknown macs allowed pool).

Item 3: TAP Windows Vista x32 client: gateway to openvpn server's lan (bridged with openvpn interface on server) client unreachable as client's arp table entry MAC all 0's and 'invalid'. All other comptuers on remote lan, including broadcast, working and reachable. Workaround:

Add this to the client config:

script-security 2
up c:
windows
system32
vpnup.bat

(replace c:
windows\... with wherever your windows is...)

Create vpnup.bat, insert:

netsh interface ip set neighbors "%dev%" %route_vpn_gateway% 00-00-5e-00-01-01 store=active

Replace the 00-00-... with whatever the MAC address is on your server's LAN interface. This will put a way to talk to the gateway in the local windows arp table, which otherwise would be missing. Once that's in the the client can get all the services including internet access via the server LAN's gateway. Openvpn client should put the gateway LAN's mac address in the windows arp table when TAP so the remote network actually is reachable.

Bug/Item? 4: No amount of fiddling with the up script's target's path, including win-sys env and other path magic works. The only to not cause openvpn client to hang on connect attempt was to fully specify the path to the script.

How to recreate all of the above (config files below):

An openvpn server 2.2.0 on freebsd, and a windows laptop (I used vista x86).

Client config, known working 2.2.0 (windows vista x86 on a laptop):

dev tap
persist-tun
persist-key
proto udp
cipher AES-256-CBC
tls-client
client
resolv-retry infinite
remote my.public.ip.address 4412
tls-remote OpenVPN Server Cert
auth-user-pass
pkcs12 gate1-udp-4412.p12
tls-auth gate1-udp-4412-tls.key 1
comp-lzo
script-security 2
auth-nocache
up c:
windows
system32
vpnup.bat

Server side:

dev ovpns2
dev-type tap
dev-node /dev/tap2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local my.public.ip.address
tls-server
username-as-common-name
auth-user-pass-verify /var/etc/openvpn/server2.php via-env
tls-verify /var/etc/openvpn/server2.tls-verify.php
lport 4412
management /var/etc/openvpn/server2.sock unix
max-clients 10
client-to-client
ca /var/etc/openvpn/server2.ca
cert /var/etc/openvpn/server2.cert
key /var/etc/openvpn/server2.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server2.tls-auth 0
comp-lzo
persist-remote-ip
float
mode server
push "route-gateway 192.168.29.1"

push "redirect-gateway"

lladdr my.lan.interfaces.mac.address
---

Server box: FreeBSD 8.1-RELEASE-p6 FreeBSD 8.1-RELEASE-p6 #1: Mon Dec 12 18:18:02 EST 2011 root@…:/usr/obj./usr/pfSensesrc/src/sys/pfSense.8 i386

OpenVPN 2.2.0 i386-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 11 2011

Hope this helps!

[Samuli Seppänen]

Uh, quite a handful. Splitting each into a separate report would have been nice. At least item 2 should be looked at, given it seems like a regression.

Can all/some of these be reproduced on 2.3.1?

[Samuli Seppänen]

Are these problems still reproducible on latest git master?

[Gert Döring]

item 2 should be tested and verified. I'm not aware of any change to the tap driver or openvpn that could explain this behaviour - but if it can be repeated, it needs fixing
(what is "the client's mac address" anyway? In TAP mode it would normally be "the virtual MAC address the TAP driver gives itself").

TAP mode and windows is not something I regularily use, so it's not as well tested...

[Gert Döring]

yeah, revisiting this. This needs more active dialogue with the reporter (but that could have been due to trac not sending mails). Pinging again, it should send mail now.

Setting milestone 2.3.5 - whatever it is, it won't be fixed in 2.3.4 "to be released this week", but after that.

[Gert Döring]

As if anyone would use TAP... anyway.

I see something here I've overlooked, and that's "--lladdr addr", which should hardwire the MAC addresse of the tap driver (as opposed to the standard behaviour of having something random). This needs to be tested if it got broken in 2.3.x for whatever reason - we didn't consciously change anything there.

Issue 1 can be achieved on the server side by adding/removing the route from --client-connect scripts. Not pretty, but the only alternative is having dynamic --route inside ccd/ which is not there because it's not easy to do.

Issue 3 (if all other MAC addresses can be resolved) very much sounds like a local problem - one would need to see tcpdumps on the client and server side here to decide whether this is an issue for us to fix or not.

Issue 4 (PATH not being used) is not something I'll invest time - specifying a full path is much more sane, especially on windows with installers filling the %PATH% with tons of paths to the most weird directories. I'd review a patch, though.

Leaves testing windows with tap and --lladdr

[Samuli Seppänen]

I'll have a look at issue 2 and report back.

[Gert Döring]

Shoving on samuli's desk - please test whether any of this can be (easily) reproduced, that is, "working on a 2.2 windows client, breaking on a 2.3 windows client", in --dev tap mode(!).

thanks a lot, feel free to throw it back to me if we know there is breakage indeed.

[Samuli Seppänen]

I'd vote for closing this bug report; all we have is the original report, and zero feedback from the original reporter or anybody else, for that matter.

As for the individual items:

1. Scrap it. According to cron2 a workaround exists. If we want a pretty solution, then we can create a separate ticket for it.
2. Scrap it. It has not been reproduced by anyone else. Moreover, it is related to the old tap-windows driver which should go away soon.
3. Scrap it. We have no way to reproduce this issue with this information.
4. Scrap it or create a separate ticket for it.

[Gert Döring]

Scrap it. If you want our help, answer our questions.