# Openvpn 2.0 + iptables How-to

## fzxdude

Ok so a bunch of my buddies have their own lans and rather than opening it up to the world we figured vpn would be the best way

effectively here is our set up

192.168.2.0

^

|

V

192.168.0.0/24 <--> 192.168.1.0/24

^

|

V

192.168.3.0/24

and so on ...

Initially we tried pptp and ppp over ssh ... but neither were that easy or efficient to use

so we went with iptables and openvpn

first for the open vpn installation

build the kernel modules for tun and tap and restart

then build openvpn 2.0

./configure && make && make install

on the server side (in our case 192.168.0.0/24):

cd /etc/openvpn/mylan

openssl dhparam -out dh1024.pem 1024

openssl req -new > new.cert.csr

openssl x509 -in new.cert.csr -out new.cert.cert -req -signkey new.cert.key -days 3650

then create a local.conf:

```
local server ip in the 192.168.0.0/24 net

port 443 #i chose this to beat the firewall at work =) 1194 is standard

proto tcp

dev tun

ca new.cert.cert

cert new.cert.cert

key new.cert.key  # This file should be kept secret

dh dh1024.pem

server 192.168.254.0 255.255.255.0 #network to make the tun0 devices in

ifconfig-pool-persist ipp.txt

client-config-dir ccd

route 192.168.1.0 255.255.255.0 #not really necessary

keepalive 10 120

comp-lzo

max-clients 100

user nobody

group nobody

persist-key

persist-tun

status /var/log/openvpn-status.log

log-append  /var/log/openvpn.log

verb 4
```

now here's the highly complicated iptables rule to run on the server:

```
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
```

now steal a init.d script from gentoo's 1.6 install ... Use this for server and client

```
#!/sbin/runscript

VPNDIR="/etc/openvpn"

depend() {

   need net

}

checktundevice() {

   if [ -h /dev/net/tun ] && [ -c /dev/misc/net/tun ]; then

      ebegin Detected broken /dev/net/tun symlink, fixing...

         rm /dev/net/tun

         ln -s /dev/misc/net/tun /dev/net/tun

      eend $?

   fi

}

start() {

   checktundevice || return 1

   

   cd $VPNDIR

   for VPN in *

   do

      if [ -d $VPN ] && [ -e $VPN/local.conf ]; then

         ebegin "Starting openvpn for $VPN"

            start-stop-daemon --start --pidfile /var/run/openvpn-$VPN.pid --startas /usr/local/sbin/openvpn -- --config $VPN/local.conf --writepid /var/run/openvpn-$VPN.pid --daemon --cd $VPN

         eend $?

      else

         ewarn "Expected $VPNDIR/$VPN to be a directory containing a local.conf."

      fi

   done

}

stop() {

   cd $VPNDIR

   for VPN in *

   do

      if [ -e /var/run/openvpn-$VPN.pid ]; then

         ebegin "Stopping openvpn for $VPN"

            start-stop-daemon --oknodo --stop --pidfile /var/run/openvpn-$VPN.pid

            rm /var/run/openvpn-$VPN.pid

         eend 0

      else

         ewarn "$VPN has no pidfile!"

      fi

   done

   return 0

}
```

On the client end set up a local.conf as we did above ... but like this:

```
client

dev tun

proto tcp

remote vpnserverinternetiporhostname 443 #443 should be replaced with whatever port is specified in the server config

resolv-retry infinite

nobind

user nobody

group nobody

persist-key

persist-tun

ca new.cert.cert

cert new.cert.cert

key new.cert.key  # This file should be kept secret

comp-lzo

log-append  /var/log/openvpn.log

verb 4

```

now because I am lazy ... I copied the mew.cert.cert and new.cert.key from the server to each client

We all use linksys routers so it was easily done on the advanced routing page:

192.168.othersubnet

255.255.255.0

vpnclientlanip

hops ... 2 worked for us

Now client iptables ...  these are set on the vpnclient to masquerade all connectionsnot meant for their lan to go outside ... but since the only packets comming here are for the vpn anyways just put it all through the tun0 device

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

and voila ... set the rules start the server and connect ... that easy

----------

## diaz

Hmm...

I've just briefly looked through this, but I have one note.

Perhaps you could use 'route' route to the other network, rather than masquerade.?

As far as I can see, I see no reason why you should have to masquerade anything between your two networks, since you have theoretically merged these to one.

But, of course, I may very well have made some wrong assumptions here.

----------

## fzxdude

well I was using masquerading particularily because I was playing with iptables at the time ...

there is no real need to have masquerading ... routing will do just fine

route add -net 192.168.2.0 netmask 255.255.255.0 dev tun0 sort of thing

----------

## daeghrefn

Are you guys using the Bridged Ethernet model or are you using the Routed IP tunnels model?

Curious, since I'm trying to research how I should set up a VPN with a few of my friends.  We're interested mostly in TCP/IP LAN gaming and filesharing.

----------

## fzxdude

routed of course ... bridged is messier anyways

----------

## daeghrefn

That's cool.  Was curious about hte bridged model since I play LAN games with keys that aren't good over the internet.  Wasn't sure if we needed to have the bridged broadcast capability or not.  Stuff like Half-Life, Homeworld, StarCraft, etc.  Those games I don't have internet valid keys, that being the reason I asked.

----------

## Lo!Mm

 *daeghrefn wrote:*   

> Wasn't sure if we needed to have the bridged broadcast capability or not.

 

Im playing with OpenVPN too. I think I need briged ethernet because broadcast packets cannot be routed. Is that right?

----------

## daeghrefn

From what I understand (which could be wrong) most LAN games in LAN mode use a broadcast model, and broadcast packets are not transmitted across the VPN tunnel.  So that is why I've been asking if the bridged model is better.

I'd like to be able to play Half-Life and StarCraft without using the general internet servers (since I don't have enough valid keys) over a VPN link.

These guys here are using the Routed model, which is more efficient (again, from my limited understanding), and say they play LAN games just fine.  So my question is (not having toyed with this yet) is the broadcast model required for LAN gaming and stuff like shared folders (samba, not nfs) and stuff.

----------

## fzxdude

well samba sharing requires you to put the ip in as opposed to looking for it in network neighbourhood, and I am not sure whether or not that has to do with the different subnet of my buddies networks or that broadcast packets arent getting routed ... havent really looked into it ... but I would hazard a guess that no, they are not being put across

----------

## thisboyiscrazy

here is a problem I am having

I have a firewall that does nating, it has 2 interfaces eth0 ( extrernal ) and eth1 ( internetal )

I am trying to get openvpn to work with bridging, when I add eth1 to the bridge nothing goes in or out of eth1.

does anyone know what I am doing wrong?

FIXED: eth1 still had the ip address

----------

