# OpenVPN but no tun0 interface

## Undo

Hi guys,

Trying to run openvpn on a dedicated server under Gentoo Linux, I installed it with the "emerge openvpn" command.

Installation completed, I got a message :

>  * It is recommended that you create your tun/tap interfaces using     

>  * the net.tun0/net.tap0 scripts provided by baselayout instead of     

>  * using the 'server' directive in openvpn configuration files.        

>  * This will insure that the interface really is up after openvpn      

>  * starts.                                                             

>  * Note that you cannot use net.tun0/net.tap0 and the server option,   

>  * otherwise openvpn will not start.  

First, I didn't warn, it's usual that installation programs say something like this a the end...

But, when I used the ifconfig command I realised I had no tun0 interface created.

So I started looking for these "scripts provided by baselayout", but impossible to find anything.

Maybe someone has already experimented this problem... can you help me creating the tun0 interface please ?

Thanks

Undo

----------

## eccerr0r

The TUNnel/ethernet TAP interface are kernel options.

CONFIG_TUN is the device driver you need in your kernel config.

I'm using the 'server' directive personally so I didn't exactly follow the warning, but this machine is a VPN server and is optional for my own use (mainly it's for using unencrypted public wifi access points.  VPN tunneling to my server is much more secure...)

----------

## Undo

 *eccerr0r wrote:*   

> The TUNnel/ethernet TAP interface are kernel options.
> 
> CONFIG_TUN is the device driver you need in your kernel config.
> 
> I'm using the 'server' directive personally so I didn't exactly follow the warning, but this machine is a VPN server and is optional for my own use (mainly it's for using unencrypted public wifi access points.  VPN tunneling to my server is much more secure...)

 

Hello eccerr0r,

Maybe "server" directive is a better idea but I don't really know how to use it.

Then where can I find this CONFIG_TUN driver ?

----------

## Undo

It seems to miss the kernel driver, in fact.

But how can I install it ? 

 *Quote:*   

> 
> 
> # /etc/init.d/openvpn start
> 
> * Starting openvpn ...
> ...

 

edit : Seeing the config-xx of my kernel ( here : ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-2.6.28.4-xxxx-std-ipv4-32 ) it seems the CONFIG_TUN is set to "y"... so it should work, what's going wrong ?

----------

## cach0rr0

maybe it's not clever enough to function unless it's a module? 

could change =y to =m, rebuild the kernel, and see if that gives you any joy

----------

## jamapii

net.tun0 is a link to net.lo

```
cd /etc/init.d

ln -s net.lo net.tun0

```

----------

## Undo

Oh, another bug is now appearing.

As the message said we need to use the "baselayout" scripts, I installed them via emerge.

But now I've this error message : 

```
-bash: ./courier-imapd: /sbin/runscript: bad interpreter: Aucun fichier ou r�pertoire de ce type

```

When I run any of the /etc/init.d script.

It seems to be the baselayout's fault, but if I try to unmerge it I've a strong message : "WARNING ! It can really damage your system to unmerge this package !!"...

What should I do ?

I'm completely lost... I've used Gentoo very little time.

----------

## cach0rr0

do NOT unmerge baselayout. please please please do not unmerge baselayout. 

Let us find out why it says /sbin/runscript is a bad interpreter first. 

Does /sbin/runscript exist on your system?

----------

## Undo

 *cach0rr0 wrote:*   

> do NOT unmerge baselayout. please please please do not unmerge baselayout. 
> 
> Let us find out why it says /sbin/runscript is a bad interpreter first. 
> 
> Does /sbin/runscript exist on your system?

 

Not anymore... (and that's why this message is appearing... !)

I've no other Gentoo to get this file, maybe it will be enough to solve the problem

I've not anymore /sbin/runscript and /sbin/runscript.sh too

I found on the web someone else had had the same problem after emerging baselayout (but it's an old post).

The guy said it solved the problem by recompiling udev, but on my system udev isn't installed... 

It seems baselayout creates a conflict with another package on my system, I think, with the package "sys-apps/util-linux-2.13" :

```
# emerge --update sys-apps/baselayout

Calculating dependencies... done!                  

!!! Error: the <sys-apps/util-linux-2.13 package conflicts with another package;

!!!        the two packages cannot be installed on the same system together.    

!!!        Please use 'emerge --pretend' to determine blockers.                 

For more information about Blocked Packages, please refer to the following

section of the Gentoo Linux x86 Handbook (architecture is irrelevant):    

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
```

----------

## Moriah

cach0rr0:  I posted elsewhere a while back on my openvpn problem.  A lot has happened since then, mostly I *FINALLY* got my consulting project off the critical path so I have some time this weekend to work on my broken openvpn tunnel.

Yesterday, it became apparent that the box I was having trouble with actually had a flakey hardware problem.  Funky symptoms started with not getting the correct time of day when I booted the system.  I booted from livecd and date gave the right answer, so I ran memory diags and badblocks -w on the drive, then when everything checked out OK, I re-installed everything.  Tried using Pappy's seed for the kernel, and on about the third boot, the box refused to complete POST in the BIOS!  Hmm... looks like sick hardware to me.

So I swapped out the box with one just like it -- or so it seemed.  Two identical looking Gateway boxes have different disk controllers in them!    :Evil or Very Mad: 

So its livecd time again.    :Confused: 

I fiddled with the drivers and got it to work, but I am still getting the same stupid message when I start openvpn: 

```

jacob ~ # /etc/init.d/openvpn.tun1 start

 * Starting openvpn.tun1 ...

 * WARNING: You are dropping root privileges!

 * As such openvpn may not be able to change ip, routing

 * or DNS configuration.                                                  [ ok ]

jacob ~ # /etc/init.d/openvpn.tun1 status

 * status:  inactive

jacob ~ #

```

Furthermore, the other end of the tunnel seems quite happy:

```

esau ~ # /etc/init.d/openvpn.tun1 status

 * status:  started

esau ~ # /etc/init.d/openvpn.tun1 stop

 * Stopping openvpn.tun1 ...                                              [ ok ]

esau ~ # /etc/init.d/openvpn.tun1 start

 * Starting openvpn.tun1 ...                                              [ ok ]

esau ~ #

```

The tun1 interface shows up on that other end, but not on this end.  

What is with the warning above anyway?  I never used to get that.

BTW  In case it matters (I suspect it is unrelated), but I cannot get X11 forwarding to work with ssh when I ssh into this miscreant box either.  It works fine with all my other machines.  I have it turned on in /etc/ssh/sshd_config:

```

#X11Forwarding no

X11Forwarding yes

#X11DisplayOffset 10

#X11UseLocalhost yes

```

I only mention the ssh X11 forwarding problem in case it might be related to the openvpn problem, which I think it is not.

Any help is appreciated!    :Very Happy: 

----------

## Undo

I solved my problem with openvpn... I think.

But due to the problem with the /sbin/runscript, I can't say for the moment if it's really working or not.

I succeeded to launch openvpn and it appears in netstat listening the right port.

I succeeded to create the interface that wasn't present... 

When I am sure all this is working, I'll post the complete solution, count on me.

But before, if anyone has an idea for this f***ing runscript...

----------

## Moriah

Undo: congrats on getting something to work!    :Wink: 

I too seem to have gotten the ssh X11 forwarding problem to work, although I'm not exactly sure how I did it.  Unfortunately, I am working on several things at once, and I sometimes loose track...    :Confused: 

Anyway, I still have the openvpn problem.    :Mad: 

----------

## cach0rr0

try updating util-linux first

then see if you can emerge baselayout

```

gentoob0x sbin # equery belongs runscript

[ Searching for file(s) runscript in *... ]

sys-apps/baselayout-1.12.11.1 (/sbin/runscript)

```

----------

## cach0rr0

@Moriah

I don't use openvpn, so I'm flying blind here. but my guess would be either

a)the init scripts are different, but both are functionally the same, and the error is purely cosmetic

OR

b)the opts pulled from your config are different from one machine to the other, so when they're passed on startup it upchucks an error. Maybe there's some .conf option that controls setuid

----------

## Undo

I've taken the files from another server who has the same configuration (they are a kind of pre-configured server, by OVH, a french hoster), then it appears there no one or two but many more files that have been modified in the wrong way... : 

```

# /etc/init.d/courier-imapd restart

/sbin/runscript.sh: line 7: /sbin/functions.sh: No such file or directory

/sbin/runscript.sh: line 9: /sh/rc-services.sh: No such file or directory

/sbin/runscript.sh: line 11: /sh/rc-daemon.sh: No such file or directory

/sbin/runscript.sh: line 38: /softlevel: No such file or directory

/sbin/runscript.sh: line 67: add_suffix: command not found

/sbin/runscript.sh: line 68: add_suffix: command not found

/sbin/runscript.sh: line 70: add_suffix: command not found

cp: can't evaluate `/started/*': No such file or directory

/sbin/runscript.sh: line 331: service_started: command not found

/sbin/runscript.sh: line 227: service_started: command not found

/sbin/runscript.sh: line 229: is_runlevel_start: command not found

/sbin/runscript.sh: line 234: mark_service_started: command not found

/sbin/runscript.sh: line 238: is_runlevel_start: command not found

/sbin/runscript.sh: line 244: ineed: command not found

/sbin/runscript.sh: line 244: valid_iuse: command not found

/sbin/runscript.sh: line 291: broken: command not found

/sbin/runscript.sh: line 296: broken: command not found

/etc/init.d/courier-imapd: line 27: ebegin: command not found

/etc/init.d/courier-imapd: line 29: eend: command not found

/sbin/runscript.sh: line 309: is_runlevel_start: command not found

/sbin/runscript.sh: line 471: service_started: command not found

```

I'm going to try updating util-linux, I'll tell you so.

----------

## Undo

Wow what a good idea updating util-linux :/ 

It took so long I was wondering if it's really updating util-linux or the entire Gentoo system... 

So after around 3 000 output lines, and finally three packages updated (?) by the simple command : 

```
emerge --update sys-apps/util-linux
```

I have a pretty message threatening me if I'm not quite enough I'll be beaten...

```
 * Messages for package sys-kernel/linux-headers-2.6.23-r3:

 * Kernel headers are usually only used when recompiling your system libc, as

 * such, following the installation of newer headers, it is advised that you 

 * re-merge your system libc.                                                

 * Failure to do so will cause your system libc to not make use of newer     

 * features present in the updated kernel headers.                           

 * Messages for package sys-libs/com_err-1.40.9:

 * PLEASE PLEASE take note of this

 * Please make *sure* to run revdep-rebuild now.

 * Certain things on your system may have linked against a different

 * version of com_err -- those things need to be recompiled.        

 * Sorry for the inconvenience                                      

 * Messages for package sys-apps/util-linux-2.13.1.1:

 * USE=crypt has been changed to USE=loop-aes.  If you need

 * support for it, make sure to update your USE accordingly.

 * Regenerating GNU info directory index...                 

 * Processed 124 info files.                                

 * IMPORTANT: 12 config files in '/etc' need updating.      

 * See the CONFIGURATION FILES section of the emerge        

 * man page to learn how to update config files.  
```

I'm quite obeidient, I started reading the man emerge page... but it says configuration files that have not been overwritten are under the "._cfgXXXX_file" form... 

I looked for this in my /etc directory but didn't find anything.

Then the revdep-rebuild command is "not found"... 

Don't beat me please ! =)

I guess it's better to find how to do what's written in this message before trying emerge --update sys-apps/baselayout again.. 

(Has someone even said the emerge system is easy to use ? I can't catch the way it's thought I think... on my desktop I've been trying several distrib and never felt so confused by a packages system O_o)

Thank you for your help, one time more  :Smile: 

----------

## cach0rr0

revdep-rebuild is part of the 'gentoolkit' package. Heaps of other very, very useful stuff in that - for future reference, it should always be one of the first things you emerge. 

With regards to the config files in /etc, normally one would run etc-update (or my preference, dispatch-conf) to resolve these changes. 

Emerge will tell you once it's finished,  when something in /etc needs to be updated; at which point you do dispatch-conf or etc-update. 

So go ahead and emerge gentoolkit. Then revdep-rebuild. Then emerge baselayout as before. 

After you've emerged baselayout, for the love of all that is holy, please go through etc-update or things will break

----------

## Undo

 *cach0rr0 wrote:*   

> revdep-rebuild is part of the 'gentoolkit' package. Heaps of other very, very useful stuff in that - for future reference, it should always be one of the first things you emerge. 
> 
> With regards to the config files in /etc, normally one would run etc-update (or my preference, dispatch-conf) to resolve these changes. 
> 
> Emerge will tell you once it's finished,  when something in /etc needs to be updated; at which point you do dispatch-conf or etc-update. 
> ...

 

Ok I follow this procedure and tell you so.

(but it will be tomorrow for me... )

Thank you =)

----------

## Moriah

Back to my openvpn nightmare...    :Confused: 

A little tcpdump sniffing on both sides revealed a curious thing: the near end (client) is originating packets that do not come from port 1194, the *OFFICIAL* openvpn port.  The firewall at the other end (and the near end as well) only permits port 1194 UDP packets to talk to other like-minded port 1194 UDP packets, so...  The far end firewall is blocking the near end openvpn's attempts at connecting.    :Shocked: 

So what did they do with the latest update?  Make the source port for the client to no longer be tied to 1194?  Why did they do this, and why didn't they say so?    :Evil or Very Mad: 

And most importantly, how can I restore the original behavior?    :Question: 

I don't really want to open up the firewall any more than necessary.

----------

## Moriah

The saga continues... 

It appears that somebody at the gentoo developer's club "had a better idea".   :Evil or Very Mad: 

The /etc/init.d/openvpn script is greatly "enhanced" over the earlier version.    :Evil or Very Mad: 

They added a couple of scripts to handle up and down events, and a bunch of stuff in the /etc/init.d/openvpn script to handle being re-entrantly called by those up and down scripts.  All well and good, and probably handy in a situation much more complex than my own.

Furthermore, they added the --nobind option if they think you are a client.  That's what is killing me.  Observe, from the docs: *Quote:*   

> 
> 
> --bind 
> 
> Bind to local address and port. This is the default unless any of --proto tcp-client , --http-proxy or --socks-proxy are used. 
> ...

 

That --nobind is what is making the port stray from the sacred *OFFICIAL* openvpn port number!    :Surprised: 

So, before I go hacking on all this stuff, and break future upgrades really good, I would like to know why they did this, and how I can *PROPERLY* override it back to the used-to-be default of --bind.    :Cool: 

My application is a simple shared secret dedicated point-to-point tunnel between 2 networks.  I do not have multiple tunnels running concurrently, and I want to keep everything on port 1194.  Surely this is still possible.

Does anyone know how to do this?    :Question: 

----------

## cach0rr0

You already have the server component bound to 1194

As I understand it, both ends run the server portion, yes? 

On the remote host you should not be filtering based upon source port

--sport any --dport 1194 -J ACCEPT (or whatever you do besides ACCEPT)

Not knowing openvpn, but just generally speaking, client connecting to a server will open a random high number port (must be one above 1024 technically) and connect to the static port on the server (1194)

SMTP, for example, my SMTP server sending a message to yours:

mx1.whitehathouston.com:33146 => yourdomain.com:25

This is perfectly normal, and expected. 

Furthermore, I can't bind to :25 for a client connection because my daemon is already bound to that port. 

In short:

Client:

-source ports are typically dynamic, technically speaking must be above 1024, in practice usually end up being >1000

-destination ports are static, in this case 1194

Server:

-source port is static, in this case 1194

-destination port dynamic

...if that makes sense? Hopefully I haven't muddied things further, but you seem to want the client to use a local data port of 1194, when it can't, because you already have another openvpn *server* instance bound to 1194 on the client. 

EX:

192.168.1.100:1194 (LONDON)

192.168.1.200:1194 (SYDNEY)

To route traffic from London to Sydney over the VPN, 192.168.1.100 opens a connection to 192.168.1.200:1194 using a random source port, from the pool of available and non-reserved ports

To route traffic from Sydney to London over the VPN, 192.168.1.200 opens a connection to 192.168.1.100:1194 using a random source port, from the pool of available and non-reserved ports

This leaves you in a scenario where you either have to add firewall rules for both source port 1194 AND source port ANY, and a destination port of 1194 - which is redundant, to say "any source port OR this specific one (1194)", or go the sensible route and filter only based upon destination port, e.g.

-s x.x.x.x --dport 1194 -J ACCEPT     #rule on Sydney box

(where x.x.x.x is the IP of the London's VPN)

-s y.y.y.y --dport 1194 -J ACCEPT     #rule on London box

(where y.y.y.y is the IP of Sydney's VPN)

If this is already something you're well aware of and I'm rehashing things you already know, my apologies - I err on the side of assuming someone *doesn't* know, rather than assuming they *do*, in the interest of providing adequate information.

----------

## Moriah

Yes, I understand everything you say, and I could open the source port to $UNPRIV_PORTS, but I have run this setup with openvpn for several years using port 1194 for both sides, and this allows me to be more locked-down and paranoid with my firewall, as I can open up only port 1194 for both source and destination.

If I was doing this for the very first time, I would open up the source port filtering to all ports, but I'm not doing it for the first time, and I want it to work the way it always did, or at least some explanation as to why thhey deemed it better to make the change they did.  Remember, the change is not in openvpn itself, but rather in the gentoo implementation of the /etc/init.d/openvpn script that starts and stops the daemon.

I think I may be able to override the --nobind in the startup script with some setting in the /etc/openvpn/tun1.conf file.    :Twisted Evil: 

No!   :Evil or Very Mad:   It bellyaches that I can't use both nobind and bind at the same time; so I can't override it that way.    :Evil or Very Mad: 

HELP!  I don't want to just hack the /etc/init.d/openvpn startup script, because then when I do the next upgrade, it will just break again.  And I don't want to weaken my firewall by being more open with the source port than I have been for the past couple of years.  What to do!    :Crying or Very sad: 

----------

## Moriah

I examined the old and the new /etc/init.d/openvpn startup scripts, and determined that the old script should still work for my purposes, so I renamed the new script to openvpn.new_broken to keep it around "just in case", and copied the old script into the /etc/init.d directory.  Now the openvpn connection gets established!    :Very Happy: 

However, this is without the firewall running on the local "client" side.  When I tried to start up the firewall, more problems ensued -- this time its all Pappy's fault!    :Wink: 

His seed for this kernel turned off all the iptables stuff that had always been on by default before, so ther was no iptables support in my kernel.    :Sad: 

Not really Pappy's fault, but I never checked the iptables stuff in the kernel because I never had to check it before.   :Confused: 

When I checked it, lo and behold, it had all become so ala carte modularized that there were bazillions of choices to make.  I am weeding thru them now.  As I write this, my first kernel build with the iptables stuff is taking place.

Stay tuned, same Bat-time, same Bat-channel...    :Rolling Eyes: 

----------

## Moriah

Forget "stay tuned"; re-tune to the following bat channel:

https://forums.gentoo.org/viewtopic-p-5945445.html#5945445

The problem was solved this morning.  It now works!    :Very Happy: 

Follow the above link for details...

----------

