Howto: RoadWarror + Tap (ip same local or far) v2.0.1 w/bug workarounds
hcoin last edited by
This is a how-to that actually works with the release versions named below (current online how-to's failed big), and includes 5 bug reports with workarounds.
There are occasions for remote tech support and in small setups it makes sense or is even necessary to cause a 'road warrior' (just a laptop, not site-to-site vpn) to act fully and in every respect from afar as if plugged in physically to a local network. Usually when it's necessary to see all the broadcast traffic in a multi-media / UPNP or windows environment, otherwise when file/printer sharing is desired in a windows environment that doesn't have or want a WINS server.
Higher security needs, diagnostic integrity and faster remote wifi speeds make it both possible and necessary to allow zero traffic on the laptop other than what it would have seen if physically connected, except for the openvpn pipe's traffic. That is to say: No traffic via the road warrior's internet other than through openvpn– full stop. While using the openvpn client, all traffic on the road is seen to originate from the office server's IP. All the windows shares 'just work', all broadcast/multicast stuff as well.
Also, in more secure settings DHCP only offers connectivity to pre-loaded MAC local link or interface addresses. It's necessary in these cases that the laptop get exactly the same IP address when plugged in locally as it would get when on the road using openvpn. So the whole openvpn "let's half duplicate dhcp services via the openvpn server" thing needs avoiding in this situation. No 'split DNS'. Besides that, who wants to maintain two separate DHCP sever setups, giving the same device a different local address depending on whether they're local or at a coffee shop in Cleveland?
It's possible but not so easy to get that going-- here's how:
Getting all that fully going on PFSense 2.0.1-RELEASE with the 'tap fix' package, using the client exporter v 2.2.0-release of openvpn as the router for the fixed lan and a vanilla windows x32 vista laptop was a nightmare, despite all the FAQ's. Here's what worked, by way of payback to the community for open source efforts:
Step 1: Install the openvpn client export package, and the openvpn tap fix pfsense packages.
Step 2: Use the wizard to get a typical openvpn tun connection going between the pfsense setup and the road warrior's laptop.
I chose UDP, use the standard open vpn port. I chose as the interface a CARP virtual IP on the WAN shared by a primary and backup PFsense box. with remote access by ssl/tls + user auth. Get that going just to the point open vpn says it connects on the windows box and the open vpn status on the pf box lists the connection. Once both sides show a connection, verify that at least one ping on each side will get something on the other side. This will call for firewall rules on a tunnel subnet which in due course will be discarded, your patience will be rewarded because it proves lots of other things are ready for the great next leap.
Bug report #1, with workaround. Only applies if you have a hot backup pfsense box running using pfsync with openvpn participating. Getting traffic to connect via the tunnel to the PFsense box sitting as a backup to the one hosting the tunnel (also running openvpn server with the same settings) needs a manual outbound nat rule on the LAN interface (your tunnel address) 192.168.24.0/24 * (the IP of 'the other' pfsense box) 192.168.29.3/32 and 'any'. This will cause traffic heading to the backup pfsense router to appear as though it came from the lan interface address of the primary router and not the tunnel. This is good since there is no connection to the tunnel on the backup pfsense box but it will still claim the route to the 'return address' and so you lose all the replies and can't communicate with the backup PF box at all absent the manual outbound nat route.
Step 3: Use the wizard again, create a new vpn server, this will be the 'full local connection emulation' one. Use the same WAN interface as before, UDP, but a different port. I like 4410-ish. Choose the same CA, server and client certificates as were known to work above from the drop down boxes, don't make new ones. I don't know that it matters for overall success but I chose AES 256 CBC.
Here's where it gets interesting. On the screen above 'tunnel settings' it should look like the tunnel version EXCEPT:
The port is different, to avoid conflict with the now working TUN server.
Choose TAP, not TUN.
Choose a different description.
Under 'Tunnel network' -- leave EVERYTHING either BLANK or UNCHECKED, other than: Current connections (your choice, I picked 10), compression (I checked this), and inter-client communication.
Under 'client settings' -- check NOTHING except:
'Allow connected clients to retain their connections if their IP address changes.' (optional, I like this.)
Here's part of the previously undocumented magic:
Under 'Advanced configuration' put:
push "route-gateway 192.168.29.1"; <-- obviously, replace this with the gateway address on your physical LAN.
lladdr 00:00:5e:00:01:01 <-- I'm not sure this is necessary given the later fixes, but use your link layer or MAC address of your LAN gateway.
Notice in my case the above is the link layer address created by CARP VIP1, as my LAN gateway is a carp virtual IP so that the backup pfsense box can take over should the main one fail. CARP arps follow a pattern all to themselves, not so much like physical interfaces and it messes with openvpn, we'll get to that.
PF Bug report / fix suggestion / work-around #2: Notice that if one doesn't click "Allow clients on the bridge to obtain DHCP." and fails to add "mode server" under advanced configuration the OpenVPN server service will fail to launch, the server status will be 'red' and the open vpn status will display a message that the server can't be communicated with. Not checking an option box should not result in the failure of the service to launch.
Save that. So, now you see this working server, but don't try connecting yet.
Step 4: Go to 'interfaces' 'assign' add a new one and make sure it is the openvpn server that is for the TAP, not the first one we created for the TUN interface. Save that, then find it, give it a decent name and enable it with 'none' as the type, in fact leave everything blank other than enabled, the description and 'none'.
Step 5. Reconsider whether a career change wouldn't be a good idea. All this fiddling-- clearly 'open source' software is far from free, the difference is you can fix it yourself and not have to wait and pay for 'the next release' in hopes 'that will fix it'. But I digress.
Step 6. Go to 'interfaces' 'assign' 'bridges'. Create a new one, add the LAN interface and the openvpn interface we just created. I chose not to enable rstp, but when I was messing about I did choose to identify the openvpn bridge as an edge port. After all, the point here is laptops connecting in and the chances of weird tunnel creation seems low enough. (Famous last words). Revisit this if you get road warriors that decide to come to a distant office, vpn in via this facility while at the same time hard connecting to the physical lan at the remote site as well.. one that that has site-to-site vpn at the home office...
Step 7: Go to firewall, rules, and there make sure to allow all (or less if you prefer later on) traffic on the openvpn interface and the bridge interface.
Save it all.
Step 8. Use the 'client exporter'. For windows clients, choose 'windows installer v 2.2'. NOT THE 2.3 BETA
Bug report #3: The 2.3 beta won't pass your windows laptop's link/MAC address to the 'home office' dhcp server, so you won't get the correct static IP configured on PFsense's DHCP LAN server page (you do have a DHCP server running someone on your lan at this point, yes?) Use the 2.2 and you will get the correct IP based on your laptop's MAC address.
Anyhow, follow the directions and otherwise get the 2.2 version going on the laptop in question. It will load, it will connect, it won't work. Don't worry.
Step 9. Right click the icon to launch openvpn under 'advanced' put 'run as administrator'. Kill off then relaunch openvpn.
Openvpn client Bug report #4: Without the below script reference and the content (listed below), the windows box arp -a will list the gateway IP as being 'unreachable'. Mac address all 0's. The result is you'll be able to talk to everything on your LAN but not the gate. No outside net, but local LAN box and broadcast access. Frustrating? Frustrating is how long it took me to narrow the problem down to an arp issue on the client. Anyhow -- Don't worry.
Step 10. Bring up 'edit config' on the openvpn gui, right click the icon in the status bar. Be sure if there is more than one choice you edit the 'tap' one, not the earlier 'tun' one. Besides all the good stuff there, add this magic at the end:
Save it. (you could add these options in at the advanced section under the 'exporter' wizard as well. I wish it saved these things in the xml!! somehow)
Bug report #5: The 'up' mechanism in the openvpn client script is severely broken, everything about using the path properly just plain doesn't work. You must fully specify the path to the script 'batch file' that we haven't yet created.
Use the notepad as administrator and create 'vpnup.bat' in the windows system32 directory (usually c:\windows\system32). Put this magic in it:
netsh interface ip set neighbors "%dev%" %route_vpn_gateway% 00-00-5e-00-01-01 store=active
Now, instead of '00-00-5e-00-01-01' put the MAC address of whatever the gateway is on your LAN subnet.
Now-- Disconnect the laptop from the inside protected lan. Make sure you're on a public, outside network. Connect using openvpn.
For me, it connects. Hope it does for you as well. What you should see if you open a command prompt and do a 'route print' is something like:
IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.29.1 192.168.29.38 30 22.214.171.124 255.255.248.0 On-link 126.96.36.199 276 188.8.131.52 255.255.255.255 On-link 184.108.40.206 276 220.127.116.11 255.255.255.255 On-link 18.104.22.168 276 my.wan.ip.here 255.255.255.255 22.214.171.124 126.96.36.199 20 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.29.0 255.255.255.0 On-link 192.168.29.38 286 192.168.29.38 255.255.255.255 On-link 192.168.29.38 286 192.168.29.255 255.255.255.255 On-link 192.168.29.38 286 188.8.131.52 240.0.0.0 On-link 127.0.0.1 306 184.108.40.206 240.0.0.0 On-link 192.168.29.38 286 220.127.116.11 240.0.0.0 On-link 18.104.22.168 276 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 192.168.29.38 286 255.255.255.255 255.255.255.255 On-link 22.214.171.124 276 =========================================================================== Persistent Routes: None
Here's what the 'arp -a' on the client should look like AFTER THE FIX:
Interface: 192.168.29.38 –- 0x1b Internet Address Physical Address Type 192.168.29.1 00-00-5e-00-01-01 static <- before the fix this would be all 00 and 'invalid'. This is the gateway! 192.168.29.10 xx-xx-xx-xx-xx-xx dynamic <- some other computer on your lan .... other computers on your lan... 192.168.29.255 ff-ff-ff-ff-ff-ff static 126.96.36.199 01-00-5e-00-00-12 static 188.8.131.52 01-00-5e-00-00-16 static 184.108.40.206 01-00-5e-00-00-fb static 220.127.116.11 01-00-5e-00-00-fc static 18.104.22.168 01-00-5e-7f-ff-fa static 255.255.255.255 ff-ff-ff-ff-ff-ff static
Where 192.168.29.1 is the LAN subnet's gateway, 192.168.29.38 is the road warrior's IP whether plugged in on the home office WIFI or hard wired or via VPN (yes!!). The 50… stuff is the DHCP public IP I got somewhere, and the 'my.wan... ' is the hidden public IP address of my pfsense box. Notice-- all traffic goes and comes as if I'm at the office physically, other than what's necessary for the open vpn client to connect to the public internet, and the one address on the public internet to the home office allowed to travel the public internet -- the encrypted openvpn traffic.
Result: A diagnostic 'road warrior' box that behaves exactly the same way (other than speed), whether on a home-office wifi, home office physical connection, or remotely via openvpn.
Whew. Hope this saves you the few days of grief it cost me! Consider it payback for my open source software use.
OpenVPN bugs reported at: http://community.openvpn.net/openvpn/ticket/233
There you will also see the specific client and server configuration files.
extide last edited by
That's an awesome write-up! I definitely could have used it a while back, I was trying to do the same thing and got stuck about step 9/10. The netsh command in vpnup.bat, that's awesome, I don't think I would have guessed that would fix it on my own!
hcoin last edited by
I think there is something that remains unhappy when a carp virtual IP (VIP) (a setup with a live failover PF box waiting) is used as the gateway on the lan side when the same PF box is used as the openvpn server via bridge and tap. It all appears to work, but there are lots of unexpected log entries. Still trying to track it down. Also remember that all the traffic goes through the tunnel, so a slow 'upload' link on the openvpn server will be felt by the road warriors…
Clearly the whole 'tap' interface idea has the clean aspect of road warriors having the same ip whether on the local wifi not via openvpn or remotely via openvpn. The biggest weakness the current openvpn tun mode has is that at least I haven't found a way to assign fixed static ip addresses to each of my road warriors--- short of creating a whole separate server instance for each of them, or just resorting to dropping the dhcp mechanism altogether and resorting to static IP's -- a pain to keep track of across the client boxes as they come and go.
A good upgrade for PFSense would be to store the XML in the openvpn client exporter, particularly the options and other details, so that later uses of the same certificate would recall the advanced options used the first time that cert was the source of an export activity.