# what broke openvpn in last update? - SOLVED

## Moriah

I am using openvpn to implement a point-to-point tunnel between 2 static ip addresses.  It is the simplest way to use openvpn.  A few days ago (maybe a week?) I did a normal routine update of both tunnel endpoints:

```

emerge --sync

emerge --update system

emerge --update world

emerge --update --deep --newuse system

emerge --update --deep --newuse world

revdep-rebuild

```

I did not reboot either system after the updates.  

This morning, the link between the 2 went down long enough to cause my power strip controller to fail a ping test over the tunnel.  This caused the power strip controller to reboot one end of the tunnel.  After the reboot, the tunnel will not come up.    :Sad: 

I remotely rebooted the other end of the tunnel just in case it was an openvpn version compatibility issue; I wanted to be sure both ends were running the latest version.  Still no joy.    :Evil or Very Mad: 

Does anyone know what might have changed in the latest gentoo update to openvpn that would cause this?    :Question: 

I did notice, in comparing the live /etc/openvpn with the copy on the backup server, that a couple of new scripts apeared: up.<something> and down.<something>   :Shocked: 

----------

## Mike Hunt

 *Moriah wrote:*   

> ...Does anyone know what might have changed in the latest gentoo update to openvpn that would cause this?

 

Nothing changed on mine after the update. 

On the server = openvpn-2.0.9

```
# cat /etc/openvpn/openvpn.conf                          

port xxxxx                                                      

proto tcp                                                           

dev tun                                                             

ca privnet/ca.crt                                                   

cert privnet/server.crt                                             

key privnet/server.key                                              

dh privnet/dh1024.pem                                               

server 192.168.25.0 255.255.255.0                                   

ifconfig-pool-persist ipp.txt                                       

keepalive 10 120                                                    

comp-lzo                                                            

user nobody                                                         

group nobody                                                        

persist-key                                                         

persist-tun                                                         

status openvpn-status.log                                           

verb 3                                                              

# cat /etc/openvpn/ipp.txt

tango,192.168.25.x

alpha,192.168.25.x

test,192.168.25.x

windows1,192.168.25.x

mybox,192.168.25.x

```

On this client = openvpn-2.1_rc19

```
# cat /etc/openvpn/openvpn.conf

client

dev tun

proto tcp

remote server.open.vpn xxxxx

resolv-retry infinite

nobind

user nobody

group nobody

persist-key

persist-tun

ca ca.crt

cert mybox.crt

key mybox.key

comp-lzo

ns-cert-type server

cipher BF-CBC

status openvpn-status.log

verb 3

```

Works perfect. But I don't know about that power strip problem. Hope this can help.  :Smile: 

----------

## Moriah

I am now running openvpn 2.1_rc15 on both ends, but it is not working.  It might be something else, as the setup here is pretty obtuse.  I could refer you to a diagram on my web server, but you can't get to it until I fix the tunnel.    :Sad: 

The power strip did its job -- no problem!  It is an iBootBar -- an ethernet connected remote controlable 8 outlet power strip with a "Rabbit" microprocessor in it.  It can be configured to ping an address a certain number of times with a specifiable delay between pings.  If it fails to get an echo within a specifiable timeout period, then it takes a specified action.  I have it configured to ping my web server, and if it times out, to drop power for 30 seconds to the web server then power it back up -- effectively forcing a reboot on the web server.  I also have it configured to ping a box in the ISP's colo-room, which goes over the aforementioned openvpn tunnel.  If it times out, then it power-cycles the tunnel box at this end, which is also the gateway router.  It also power-cycles the DSL bridge/modem at the same time, just to cover all the bases.  I have a similar setup at the other end of the tunnel in the ISP's colo-room.  

I use openvpn to transport a block of static IP addresses from my ISP over the internet to my network, which is many miles away from the ISP.  I get my DSL connection from the phone company,and they want an absurd price to give me a block of static IP's.    :Evil or Very Mad: 

So my basic setup is that the gateway firewall/router at my place is also an openvpn tunnel endpoint.  It connects to a DSL bridge/modem that goes over the phone lines to the phone company, where it gets a dynamic IP addresss from their DHCP server.  It then opens an openvpn tunnel to the other tunnel endpoint in the colo room of my ISP.  (My ISP is *NOT* the phone company; they are just my DSL provider!  My ISP is iglou.com in Louisville Kentucky US, and they are great.  The phone company is Cincinnati Bell, and they *STINK*!  Just think, "If you'd like to make a call. please hang up."  How stupid is that?  How you gonna make a call if the phone is hung up?  DUH!   :Evil or Very Mad:  )  I transport a block of static IPs from my ISP over the openvpn tunnel to my network.

I have several of these power strips.  They can be ganged together to use one network interface and IP address, and to cooperate with each other for automatic actions.  They also cause devices to sequence during a full power up.  If the whole power  strip looses power, then when it comes back up, it turns on outlet one, then waits a specified interval, then turns on outlet 2, waits, then turns on 3, etc.  This keeps from putting a big surge on the mains when power fails and is restored.  Of course, the power strips are plugged into a big UPS, so that only happens if power s out for a while.   :Cool: 

I also have an iPEPS on my KVM switch, so I can remotely view and control all the consoles of the machines on my network.  I have another iPEPS on the tunnel server at my ISP.  The iPEPS is a vncserver in a little hardware box that has a keyboard connector, and mouse connector, and a VGA 15-pin D-shell video connector on it.  You just plug the video cable from the computer or KVM switch into the iPEPS, and do likewise with the keyboard and mouse cables.  Then you plug an ethernet cable into the iPEPS, and Voila!  You have access to your boot consoles via a vncviewer over the network. You can force a reboot with the iBootBar, and watch the boot screen over the iPEPS.  You can change BIOS parameters, etc. remotely.  Once the computer is booted, you have a remote console login that does not rely on the computer's ethernet connection, only the iPEPS's ethernet connection.  I keep a gentoo liveCD in the CD drive of each computer, so if something *REALLY* bad happens, I can reboot it, tell the BIOS to boot from CD instead of the hard drive, and I have a recovery mechanism.  I can even install a whole new system from scratch.

I am a consultant, so I travel a lot.  I am also my own system administrator, as I have no one else to do that for me.  With the above iBootBar and iPEPS setup, I can handle almost everything except a hardware swap-out by remote control.    :Cool: 

----------

## Mike Hunt

Moriah,

Larry the Cow! What a setup!

Once there was internet downtime here everyday at around the exact same time every day. At the time my ISP was the phone company (which BTW stank like yours - bell.ca).

I knew that the problem was not at my end, but it took me calling there everyday single day for 2 solid weeks, telling them that the problem was at their end,  for them to admit it, then it took less than one minute for them to fix it.   :Shocked: 

And you have 2 middle points that are pretty much out of your direct control.

I guess you'll have to put on your Sherlock Holmes hat and eliminate the impossible, then whatever remains, however improbable must be where the glitch is.  :Smile: 

That probably doesn't help much.  :Sad: 

Cheers,

M

----------

## Moriah

Who is Larry the Cow?    :Question: 

Anyway, when I log into the gateway firewall/router/tunnel-endpoint at my end and fiddle with the firewall and routing rules, I can connect to the internet and even get to the other tunnel endpoint, so I know the problem is at this end.

Furthermore, when I run:

```

tcpdump -i eth1 port openvpn

```

I never see a single packet, so maybe openvpn is OK and the firewall got clobbered somehow.  I did a quick look at the rules with:

```

iptales -L

```

but it looked reasonable at first glance.    :Confused: 

And on top of everything else, I'm facing a very tight deadline on a consulting contract, and I *HAVE* to work on that, which severely limits my time to work on this!    :Crying or Very sad: 

----------

## Mike Hunt

Is your openvpn running on the default port?

Sometimes I put stuff on nonstandard ports and then I forget.   :Neutral: 

You don't know  Larry the Cow? holy cow's brother.   :Cool: 

----------

## Moriah

Oh!  The 2-cows cow...

Larry the cow's brother is Chinese:  Ho Lee Kow    :Wink: 

Yes, I am using the standard openvnc port 1194.

----------

## cach0rr0

 *Moriah wrote:*   

> 
> 
> I never see a single packet, so maybe openvpn is OK and the firewall got clobbered somehow.  
> 
> 

 

If iptables is dropping stuff, shouldnt tcpdump show you a count of the packets "filtered by the kernel" I believe is the term it uses? 

That is of course once you CTRL+C, should be part of the message 

Ruling the application in or out is ultimately as simple as

```

emerge netcat

ServerA: nc -l <port>

ServerB: nc serverA.ip.add.ress <port>

```

If that's successful, you can rule iptables out as a culprit more than likely.

----------

## Moriah

Not likely I'm missing a driver, as this openvpn tunnel had been working for several years.  Pain in the kazoo that I'm so busy with money earning work for a consulting client that I don't have much time to work on this.  It pains me, because my email is down, and my web server is down, as they both get their internet connection via this tunnel.

I will have to try your tcpdump then ^C test and see if I have been overlooking any important clues.  Thanks for the tip!   :Very Happy: 

----------

## Mike Hunt

Every time I had that kind of problem on my end it was always iptables (when I was fiddling with it), and just flushing them wasn't enough. 

Normally I only reboot a new kernel, but when the iptables fail to flush properly, I was only able to correct that by rebooting.

Cheers,

----------

## Moriah

I have rebooted both ends of the tunnel several times now...    :Sad: 

To add insult to injury, the USB backup drive at the remote end at my ISP seems to have failed, so I have to go there today and fix that.    :Evil or Very Mad: 

----------

## Moriah

This thread continues under a new thread...

https://forums.gentoo.org/viewtopic-t-788997-highlight-.html

Go there for "the rest of the story".    :Smile: 

BTW it is SOLVED there, hence also here.

----------

