# Multiple instances openvpn

## cazze

Hi,

how could i run multiple instances of openvpn on a gentoo box? I would like to run the UDP and TCP server, and a client connection.

Is this possible with the default init scripts?

Thx,

kammicazze

----------

## bigfunkymo

the init scripts will start a new instance of OpenVPN for each conf file in /etc/openvpn

----------

## cazze

 *Quote:*   

> the init scripts will start a new instance of OpenVPN for each conf file in /etc/openvpn

 

are u sure of this?

i'm talking about openvpn 2.0.1.

It says my configuration file should be /etc/openvpn/*/local.conf.

Do i have to put local.conf files in each directory op the different instance of openvpn i want, like this:

/etc/openvpn/server_udp/local.conf

/etc/openpvn/server_tcp/local.conf

/etc/openvpn/client_1/local.conf

...

kammicazze

----------

## bigfunkymo

I have mine set up like so:

configuration file

/etc/openvpn/priest-server.conf

keys, etc

/etc/openvpn/priest-server/

client-configs:

/etc/openvpn/priest-server/client-configs/

and it works just fine for me

----------

## yottabit

The new OpenVPN (2.0.5-r2) init script seems to expect a single openvpn.conf in /etc/openvpn/ in order to start. This of course bjorked my config since I had two instances/configs running (one for UDP, one for TCP). I just made two copies of the init script in /etc/init.d/ and customoized one for my UDP config file and the other for my TCP config file.

Not glamorous, but it works...

----------

## nobspangle

which fool decided to change this.

My VPN has a version 2 style vpn for multiple single clients and a version 1 style point-point vpn for joining to remote networks.

I've just hacked the init files so it works again.

----------

## nobspangle

grrr always read the info

the new init script works like this

you put all your configuration files into /etc/openvpn

call your config files vpn-name.conf e.g. I've called mine RAS.conf and leeds-manchester.conf

create symlinks to the init script and call them openvpn.vpn-name

```
ln -sf /etc/init.d/openvpn /etc/init.d/openvpn.RAS

ln -sf /etc/init.d/openvpn /etc/init.d/openvpn.leeds-manchester
```

remove the openvpn script from the default run level and add the new symlinked ones you have created

for the most part the info at the end of ebuilds is a waste of time, unless you sit there and watch your packages compile. This information should be logged to the emerge.log so you can review it easily later.

----------

## UberLord

 *nobspangle wrote:*   

> which fool decided to change this.

 

That would be me  :Twisted Evil: 

The new init script has been in ~ARCH for many months now with little compliant and it provides a much better solution.

 *Quote:*   

> for the most part the info at the end of ebuilds is a waste of time, unless you sit there and watch your packages compile. This information should be logged to the emerge.log so you can review it easily later.

 

Checkout portage-2.1_pre series - it supports the PORTAGE_ELOG_* stuff that makes logging and reviewing easier.

----------

## Braempje

This information was very valuable to me and I was unable to easily locate it. Mods: could you please make this one sticky for a while? Thanks!

----------

## Raffi

[quote="UberLord"] *nobspangle wrote:*   

> 
> 
> That would be me 
> 
> 

 

Ahh... Now I have a direction to direct my grumbling.   :Wink: 

So, is the openvpn config de jour a result of multiple personalities, indecision nor infighting among developers?   :Smile:   Sorry, just had to say something, the regular changes have been making me very wary of upgrading certain machines.

On a more serious note, is the current setup likely to stick for a while? Should I go ahead and switch to it with some expectation of it being the standard approach?

----------

## Raffi

For the record, the current config setup seems to be the best one so far. Let's hope we keep it.   :Smile: 

----------

## UberLord

 *Raffi wrote:*   

> Ahh... Now I have a direction to direct my grumbling.   

 

Uh oh!

/me runs for the hills  :Laughing: 

 *Quote:*   

> So, is the openvpn config de jour a result of multiple personalities, indecision nor infighting among developers?    Sorry, just had to say something, the regular changes have been making me very wary of upgrading certain machines.

 

Simply the case that openvpn has changed maintainers a fair few times and each maintainer as a different view to solving bugs. IMO at least 2 bugs could not have been fixed without the current script.

 *Quote:*   

> On a more serious note, is the current setup likely to stick for a while? Should I go ahead and switch to it with some expectation of it being the standard approach?

 

The counterpoint is that work still needs to be done, but the current config setup and layout is now "fixed" for as long as I'm the maintainer.

----------

## Raffi

 *UberLord wrote:*   

> 
> 
> The counterpoint is that work still needs to be done, but the current config setup and layout is now "fixed" for as long as I'm the maintainer.

 

Well I like the current way of doing thing a lot, so I hope you keep maintaining it for the foreseeable future.

Thanks.

----------

## dcmwai

Let me try to help.

Put the following in your openvpn.conf

#openvpn.conf

cd full/path/vpn1

config local.conf

cd full/path/vpn2

config local.conf

#end

Try this way  :Smile: 

----------

## BlaaT0001

I for one am quite fund of the new baselayout. I'm now able to stop any one of my particular openvpn instances.

I do have some questions though. After emerging openvpn-2.0.5-r2 the following message appears on screen:

 *Quote:*   

> 
> 
> It is recommended that you create your tun/tap interfaces using"
> 
>  "the net.tun0/net.tap0 scripts provided by baselayout instead of"
> ...

 

How would I accomplish this exactly? 

Normally if I start my OpenVPN tun instance with the "server" directive set (server 172.24.1.0 255.255.255.224), Openvpn takes care of creating my tun device. The log file shows:

```

/sbin/ifconfig tun0 172.24.1.1 pointopoint 172.24.1.2 mtu 1500

/sbin/route add -net 172.24.1.0 netmask 255.255.255.224 gw 172.24.1.2

```

I've tried to modify my /etc/conf.d/net file and created a symlink net.tun0 to net.lo

in /etc/conf.d/net the following line now resides:

```

config_tun0=("172.24.1.1 pointopoint 172.24.1.2")

```

This doesn't do the trick though  :Sad:  I've tried some alternatives but no luck so far.

I have managed to get the tun0 device up and running manually, but not using the baselayout scripts, not in a pointopoint mode that is.

Also, I haven't been able to add the required routes to my kernel routing table using the baselayout scripts. Is there any room for routes in the config files for networking?

When the net.tun0 device is activated the tun0 device should be configured with the right IP, in point-to-point mode and the right routes should be added to the routing table. Otherwise I'll better take my chances with Openvpn creating the tun0 device for me and adding the routes to the kernel routing table.

I can imagine though, when using Openvpn in bridge/TAP mode it's preferable to have the interfaces up and running, the bridge (net.br0) created before starting Openvpn. This way the whole bridge creation is not depending on Openvpn to run or not.

So, how should the /etc/conf.d/net file look like when using the new baselayout with Openvpn-2.0.5-r2?

Cheers,

BlaaT

----------

## BlaaT0001

Adding the routes is done with:

```

routes_tun0=( "172.24.1.0 netmask 255.255.255.224 gw 172.24.1.2" )

```

With my tun0 device having the IP address 172.24.1.1 this would route traffice for the 172.24.1.0/27 network to OpenVPN which has a P-t-p connection with the tun0 device.

I just can't seem to manage to get the tun0 device up and running in Point-to-point mode using the /etc/conf.d/net file.

Any help anyone?

Thanks,

BlaaT

----------

## UberLord

You have emerged usermode-utilities haven't you?

----------

## BlaaT0001

Yes, I've got: sys-apps/usermode-utilities-20040406-r1

This is how my tun0 virtual nic is configured when I use OpenVPN to configure it:

```

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          inet addr:172.24.1.1  P-t-P:172.24.1.2  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

          RX packets:426 errors:0 dropped:0 overruns:0 frame:0

          TX packets:426 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:27196 (26.5 Kb)  TX bytes:28180 (27.5 Kb)

```

If I use the "/etc/init.d/net.tun0" script (which in linked to /etc/init.d/net.lo) and I use the following config in my /etc/conf.d/net file:

Snip from /etc/conf.d/net

```

# OpenVPN TUN interface

config_tun0=( "172.24.1.1 pointopoint 172.24.1.2" )

routes_tun0=( "172.24.1.0 255.255.255.224 via 172.24.1.2" )

```

the tun0 interface does not start properly.

Output of "/etc/init.d/net.tun0 start":

```

* Starting tun0

 *   Creating Tun/Tap interface tun0 ...                                  [ ok ]

 *   Bringing up tun0

 *     172.24.1.1                                                        [ ok ]

 *   Adding routes

 *     172.24.1.0 255.255.255.224 gw 172.24.1.2 ...                     [ !! ]

```

ifconfig tun0 outputs:

```

tun0      Link encap:Ethernet  HWaddr E6:79:E7:7E:CD:B2

          inet addr:172.24.1.1  Bcast:172.24.255.255  Mask:255.255.0.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:500

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

```

Notice the difference in configuration of the tun0 interface?

/etc/init.d/net.tun0 stop outputs:

```

* Stopping tun0

 *   Bringing down tun0

 *     Destroyed Tun/Tap interface tun0                                   [ ok ]

```

I hope anyone has got some suggestions.

Thanks,

BlaaT

----------

## mnagl

Same Problem here.

Matthias

----------

## UberLord

This should be fixed with baselayout-1.12.0_pre17-r2

----------

## mnagl

Thank you very much!

How long will this probably need to go stable?

yours

Matthias

----------

## UberLord

 *mnagl wrote:*   

> How long will this probably need to go stable?

 

Not long now. We've already started the process by marking bash-3.1 stable. Then I will be marking the required dhcp clients around the middle of next month and probably do a pre18 which should be the last unstable version of 1.12.

So probably around 2 months.

On the other hand, the more users that use 1.12.0_pre now and report any issues makes it easier for others. So the more people that test the quicker things get done  :Smile: 

----------

## mrfree

/var/log/openvpn.log

```
Sun Aug  6 19:18:36 2006 TUN/TAP device tun0 opened

Sun Aug  6 19:18:36 2006 /sbin/ifconfig tun0 10.11.12.1 pointopoint 10.11.12.2 mtu 1500

Sun Aug  6 19:18:36 2006 /sbin/route add -net 10.11.12.0 netmask 255.255.255.0 gw 10.11.12.2

Sun Aug  6 19:18:36 2006 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
```

So I've added to /etc/conf.d/net

```
config_tun0=( "10.11.12.1 pointopoint 10.11.12.2" )

routes_tun0=( "10.11.12.0 netmask 255.255.255.0 gw 10.11.12.2" )
```

```
# /etc/init.d/net.tun0 start

 * Starting tun0

 *   Bringing up tun0

 *     10.11.12.1

 *     network interface tun0 does not exist

 *     Please verify hardware or kernel module (driver)                   [ !! ]
```

Tun module is loaded.

```
# lsmod | grep tun

tun                     8608  0
```

```
[I--] [ ~] sys-apps/baselayout-1.12.4-r1 (0)

[I--] [  ] sys-apps/usermode-utilities-20040406-r1 (0)
```

----------

## VPN-User

Same here. Funny (is it?) thing is, it works when doing an "/etc/init.d/net.tap0 start" after login.   :Rolling Eyes: 

I wonder how a new baselayout can go stable when it has not been tested with all features?

----------

## UberLord

 *VPN-User wrote:*   

> I wonder how a new baselayout can go stable when it has not been tested with all features?

 

I use OpenVPN to create tap interfaces every day. I know of another Gentoo developer who uses tun instead.

Maybe we didn't have enough people testing with a wide variation of configs and hardware this time - care to help next time?

Do you have hotplug enabled in the kernel?

----------

## VPN-User

 *UberLord wrote:*   

>  *VPN-User wrote:*   I wonder how a new baselayout can go stable when it has not been tested with all features? 
> 
> I use OpenVPN to create tap interfaces every day. I know of another Gentoo developer who uses tun instead.
> 
> Maybe we didn't have enough people testing with a wide variation of configs and hardware this time - care to help next time?
> ...

 

I got it working again. I' ve had to add 'tuntap_tap0="tap"' to /etc/conf.d/net to get it to work. It defenitely worked without that line before.

This is something I hate when using Gentoo: Things got changed somewhere without letting the user know. One reboots and things go mad. I use x86 stable because I think it is and things don' t change every other day. And adding some comments to an ebuild is NOT enough, IMHO. Most users can' t even read these messages as they scroll by. Don' t take that personal!

----------

## UberLord

 *VPN-User wrote:*   

> This is something I hate when using Gentoo: Things got changed somewhere without letting the user know. One reboots and things go mad. I use x86 stable because I think it is and things don' t change every other day. And adding some comments to an ebuild is NOT enough, IMHO. Most users can' t even read these messages as they scroll by. Don' t take that personal!

 

OK, aside from emailing you personally about changes how do you suggest we inform you?

----------

## VPN-User

 *UberLord wrote:*   

>  *VPN-User wrote:*   This is something I hate when using Gentoo: Things got changed somewhere without letting the user know. One reboots and things go mad. I use x86 stable because I think it is and things don' t change every other day. And adding some comments to an ebuild is NOT enough, IMHO. Most users can' t even read these messages as they scroll by. Don' t take that personal! 
> 
> OK, aside from emailing you personally about changes how do you suggest we inform you?

 

I think this is something portage should take care of. Aside from the updated files there should be a changelog available to the user which just shows important changes he should _really_ take care of. These are especially _important_ changes to config files or how options are handled or formatted. etc-update and just showing the differences between files is a way, but not a very user friendly one. For example when the syntax of some baselayout options got changed (this happened in the past and not only one time!), showing the differences between user' s customized /etc/conf.d/net and the updated /net/conf.d/net is just useless because it only consists of the defaults. That way the user will never know of the changed syntax until something gets wrong (most often when he reboots, which is perhaps days later so will he never find out what exactly may caused this). You understand what I mean? At least an emerge history would help partially.

I don' t have an exact idea of how this should be handled, but I think there is need for a solution of that problem.

----------

## UberLord

 *VPN-User wrote:*   

> I don' t have an exact idea of how this should be handled, but I think there is need for a solution of that problem.

 

You could always diff the net.example (your current version and the new version) to see any network related changes easily.

But no, we don't have an easy way of informing the user about all the changes.

----------

## VPN-User

What about the suggestest ebuild history? It should log when, who, what version and which configfiles have been updated by an emerge.

----------

## mrfree

 *UberLord wrote:*   

> Do you have hotplug enabled in the kernel?

 

```
# cat .config | grep HOTPLUG

CONFIG_HOTPLUG=y

# CONFIG_HOTPLUG_PCI is not set
```

I suppose my config files (my prev post) are correct.

----------

## UberLord

You need tuntap_tun0="tun" in your config

----------

## mrfree

 *UberLord wrote:*   

> You need tuntap_tun0="tun" in your config

 

Ok now tun0 coming up correcly using net.tun0 script, thanks  :Smile: 

But... I noticed that openvpn however try to setup device

```
Fri Aug 18 12:39:35 2006 us=160261 TUN/TAP device tun0 opened

Fri Aug 18 12:39:35 2006 us=160463 TUN/TAP TX queue length set to 100

Fri Aug 18 12:39:35 2006 us=160643 /sbin/ifconfig tun0 10.11.12.1 pointopoint 10.11.12.2 mtu 1500

Fri Aug 18 12:39:35 2006 us=185171 /sbin/route add -net 192.168.3.0 netmask 255.255.255.0 gw 10.11.12.2

Fri Aug 18 12:39:35 2006 us=208422 /sbin/route add -net 10.11.12.0 netmask 255.255.255.0 gw 10.11.12.2

SIOCADDRT: Il file esiste

Fri Aug 18 12:39:35 2006 us=231530 ERROR: Linux route add command failed: shell command exited with error status: 7

```

I simply used dev tun0 instead of dev tun in openvpn.conf, do I need to change something else?

----------

## UberLord

Looks it's bailing on adding the 2nd route - is that set somewhere else already?

----------

## mrfree

Ok the problem was the server parameter in openvpn.conf

 *man openvpn wrote:*   

> --server network netmask
> 
>     A helper directive designed to simplify the configuration of OpenVPN's server mode. This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.
> 
>     For example, --server 10.8.0.0 255.255.255.0 expands as follows:
> ...

 

I simply split "server 10.8.0.0 255.255.255.0" over openvpn.conf 

```
mode server

tls-server

ifconfig-pool 10.8.0.4 10.8.0.251

push "route 10.8.0.0 255.255.255.0"
```

and net.tun0

```
tuntap_tun0="tun"

config_tun0=( "10.8.0.1 pointopoint 10.8.0.2 mtu 1500" )

routes_tun0=( "10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 metric 0")
```

Now all seems to works well  :Wink: 

----------

## Helix

Two years later, and still the same problem:

Doing exactly the thing above I do not get a connection, when I split the commands. The logs look identical and so do the routing tables on both ends. Still, the "server" directive is working, while the other commands are not. I have no idea what this might be. Any idea ?

Thanks.

----------

## Helix

Ok, problem was solved:

Instead of using

```
tuntap_tun0="tun"

config_tun0=( "10.8.0.1 pointopoint 10.8.0.2 mtu 1500" )

routes_tun0=( "10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 metric 0")
```

one has to use

```
tuntap_tun0="tun"

config_tun0=( "10.8.0.1 peer 10.8.0.2 mtu 1500" )

routes_tun0=( "10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 metric 0")
```

which uses iproute2 instead of ifconfig. Now everything is working.

----------

