I'm having a bit of a dim moment again! I gave up on Centos and went back to Debian. As much as I love Debian, I still get confused with it.

I'm following this guide on how to set a OpenVPN up http://www.monkeedev.co.uk/blog/2009/03 ... ianubuntu/ , but I'm confused on what exactly to put down on the server bridge and push lines.

It says I need to put the 'gateway, subnet mask, and the start and end IP’s to assign the clients, and the push route, which pushes specific routes to all clients.'

Well I do a netstat -r and it says the default gateway is gateway140.lino. Is that right?? Obviously I know what the subnet address is, but then I have no idea what to put for the start and end ips to assign to clients. No clue about what to put for the push router.

I'm sure someone must have successfully set up OpenVPN on Debian.

Why do you give up on CentOs? I ask because I am toying with the idea of switching to CentOS.

Well there's nothing wrong with Centos. It's not difficult, but I find there are more guides on how to do things with Debian based systems. Things differ on Centos.

Whether or not you need to push anything to clients is dependent on the sort of configuration you want to set up. If you just need your clients to be able to reach your Linode (but not route through it), then much of that is unnecessary. The page you reference is setting up a full bridged environment (essentially making it like your clients are on the same network as the Linode) whereas a simple routed setup is easier if they just need secure access to the Linode itself and/or other concurrent VPN connections. Bridging also needs more work to set up the bridging device on Linux that connects the OpenVPN interface with the main LAN interface.

(Personally, I also wouldn't use port 443 which is the HTTPS port).


The network that is used for the VPN connection itself is distinct (and will have its own tun* or tap* adapter on your Linode) from the Linode's ethernet. So you can pick any non-conflicting address range to use for it. Typically this will be from the "private" reserved address space. Most OpenVPN samples will use the 10.* space, which among other things is less likely to conflict with the private address space used by home routers.

The openvpn package on Debian would have included several sample configurations in /usr/share/doc/openvpn/examples/sample-config-files. The sample server.conf.gz file is a pretty straight forward routed server, using the 10.8.0.* address space for clients.

You might try starting with that as a simpler configuration, and once that's stable progress to bridging if you need it.

The openvpn site also includes some good documentation (http://www.openvpn.net/index.php/open-s ... ation.html) including entries that help describe the difference in behavior and configuration between routed and bridged configurations.

-- David

EDIT: Oops didn't realize this thread was so old!



Now I just set up openvpn on my ubuntu (with routing instead of bridging) so I may be able to shed some light.

Openvpn creates a virtual interface tun0 which bridges over your network interface eth0. This is what my "ifconfig tun0" looks like:

tun0     
 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          [b]inet addr:10.0.0.1  P-t-P:10.0.0.2[/b]  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1328855 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2496144 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:81471960 (81.4 MB)  TX bytes:3449615843 (3.4 GB)

So here 10.0.0.1 is my openvpn server ip (think of it as your eth0 ip) and when any client connects to it it get's ip from that range (ex my laptop get 10.0.0.5 -> 10.0.0.6)

So these private ips and it's range is what you need to put in your server.conf. It can be either the 10. series or 172 or 192 series of private ips and their range for the clients.

Does this help?

PS And yes, I wouldn't run it on 443 since it is https port too. Run it on it's default port 1194