Talk:OpenVPN

Latest revision as of 21:24, 22 July 2007

the tunnel marked #0 is the windows one, no? just checking to make sure...

--Dave 13:49, 8 June 2007 (EDT)

[edit] I'm curious here and I dunno

does the network on the inside of the VPN need to be routeable outside the vpn?

Let's say I'm RoadWarrior#1, public IP is 256.1.1.1 and private IP in the hotel I'm at is 192.168.0.123, and I connect to the VPN as set up on the article page -- I will be getting a 10.10.11./26 address or whatever it is (not checking just now....). Does my traffic from inside the VPN to machines in the VPN's network (a work resource like a share or printer or whatever) get natted out as the VPN itself or the addresses of the taps?

--Dave 15:27, 19 July 2007 (EDT)

[edit] how it works

> public IP is 256.1.1.1 
> private IP in the hotel I'm at is 192.168.0.123
>
> I connect to the VPN as set up on the article page

There is no NAT. You'll have a (static by your openvpn.conf file) private IP address, which your office's network needs to know how to route to. Your office neither knows nor cares what the "Local Area Connection" IP address is, ie the hotel's 192.168.0.123 - the office isn't speaking to that; the office is speaking to the OpenVPN adapter with the 10.10.10.2 address. By contrast, your road warrior workstation gets a route set up (again, statically by way of openvpn.conf) that tells it to route all traffic for the office's subnet(s) through 10.10.10.1 - which is the tap IP address for the OpenVPN server in the office.

Ideally you want the default gateway for the office to know to route any packets for 10.10.10.x through the office IP address for the OpenVPN server, so that the road warrior can access the entire subnet(s) at the office without having to worry about whether each individual machine there has been set up to route through the OpenVPN server.

Capiche?

There are other ways to do it, but that's the way I do it. (PS you only really need a /30 for the OpenVPN subnet - the only two machines on it are the OpenVPN server and the road warrior. The OpenVPN server will probably have quite a few tap interfaces, each with their own tiny subnet, which you connect your road warriors to. Again, that's the way I do it at any rate. It's possible to do it differently, but I currently don't.)

--Jimbo 19:21, 19 July 2007 (EDT)

[edit] ahhhhh

i gets it better now. well, my office is a switched environment, but my VPN will be in the DMZ, which because of the placement of the FW will mean my route will go on my FW. Easy-peasy.

danke schoen Jimboner

--Dave 23:18, 19 July 2007 (EDT)

[edit] a little clarification on the way I typically do it

Office: public external IP 64.64.64.64, private internal subnet 172.16.200.1/24 Remote: public external IP 85.85.85.85, private internal subnet 192.168.0.1/24 OpenVPN: tap adapters are 10.10.10.1 and 10.10.10.2, with .2 being the remote machine

The remote machine knows (by way of openvpn.conf) to initiate tunnel connection with 64.64.64.64. Having done so, it also knows to route all traffic for 172.16.200.1/24 through 172.16.200.250, which is the IP address of the OpenVPN server, and does so on port 4900 (for example) which the office router NATs in. The office router ALSO knows to route all traffic for 10.10.10.1/24 through 172.16.200.250 (the OpenVPN machine).

So when our road warrior makes an SMB connection to the server at 172.16.200.249, what happens is that the OpenVPN server gets that request on its tap interface at 10.10.10.1, routes it through its eth0 connection to the actual 172.16.200.249 fileserver, the fileserver replies to the originating tap IP address - 10.10.10.2 - which it routes through the office router (as default gateway), the office router knows that all traffic for 10.10.10.x goes through the OpenVPN server at 172.16.200.249 and therefore sends it that way, and the OpenVPN server picks that up on its eth0 and routes it through its tap across the tunnel to the road warrior's tap interface.

There isn't really any NAT involved, except at the hardware level for the office to punch a hole through. After that, it's all routing.

I know for a fact it's POSSIBLE to set up dhcp and NAT and all sorts of stuff, but in my environments I've never needed more than ten or twenty simultaneous tunnels so I've always set them up statically on multiple tap adapters - with the added benefit that that way I also have an easy way of tracking what user's tunnel is doing what, since their IP addresses are always different. Anything EVER that happens with a 10.10.10.2 origin is Bob, anything EVER that happens with 10.10.10.4 origin is Jenny, etc etc etc.

--Jimbo 22:24, 22 July 2007 (EDT)