[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] reverts to port 1024 and then doesn't process replies

  • Subject: Re: [Openvpn-users] reverts to port 1024 and then doesn't process replies
  • From: "Brian J. Murrell" <brian@xxxxxxxxxxxxxxx>
  • Date: Tue, 28 Aug 2007 00:58:18 -0400

On Sun, 2007-08-26 at 20:54 -0400, Brian J. Murrell wrote:
> I have an openvpn connection between my OpenWRT White Russian 0.9 which
> has openvpn 2.0.8 in it.  On the other end I have a Ubuntu Feisty
> machine with openvpn 2.0.9 on it.
> The connection between the two will come up successfully, with in most
> cases, the 2.0.9 version side originating the connection and
> communication will commence.
> I have been having problems however, wherein the 2.0.8 side of the
> connection will at some point revert to using port 1024 as it's source
> address.  The 2.0.9 side will happily receive those packets (1024->1194)
> and send replies back to the 2.0.8 side on port 1024.  The openvpn
> instance on the 2.0.8 side will receive these replies and process them
> but the result is that the encapsulated packet will not be put onto the
> tap0 interface.

I have created a connection to a different machine from this troublesome
2.0.8 machine and it yields even more interesting results.

It seems that even when the 2.0.8 side is using port 1024 as it's
source, packets will successfully be decoded and put onto the tun
interface and all will work well.

Also there are situations where the 2.0.8 side will be using it's
allocated port (1195 for this new connection) as it's source and yet
packets will not make it onto the tun interface.

So this port 1024 or 1195 as the source address does not seem to be
directly related to this issue where packets travelling from the remote
to the 2.0.8 will be received and processed by the 2.0.8 side, yet they
will not appear on the tun interface.

When the connection is stuck in this mode of receiving packets from the
remote but not putting them onto the tun interface, I can usually make
things flow again by simply sending the 2.0.8 side a SIGHUP.

Any ideas as to what could be going wrong and/or how to further debug?


A day in the yard with my son is just like a day at work.  He goes
hunting around for stuff and brings it back to me and says: "Hey Dad,
look what I found.  The money is for me and the screw is for you."

Attachment: signature.asc
Description: This is a digitally signed message part