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

Re: [Openvpn-devel] On the way from tun0 to eth1, packets disappearing.

On Mon, 13 Nov 2006, H.Shrikumar wrote:

> I have been trying to set up openvpn to cross-connect two LANs
> together. I have a slightly complicated goal, and I believe
> I have it almost(!) working, except that at one point, the
> packets vanish without a trace. And it seems to vanish in the
> kernel, of all places, which is rather puzzling!!
> I have two LANs, and two identical routers (soekris/picodebian
> linux boxes) connecting them together. Each has a openvpn
> server and an openvpn client, connecting cross to the other. (I
> have also tried it with just one link, but my problem is not
> solved. Further, I think I need the symmetrical cross-connect
> for a bunch of other reasons -- so unless this is a no-no,
> please humour me).

Strange - I find that as long as the routers have static addresses, one
process on either side is sufficient since either one can reestablish
the connection. But this is more for the -users list.

Did you try using a "tap" connection (on Linux, be sure you're using the
tun module - which includes the tap driver -, not ethertap -- the
framing of the latter is incompatible with OpenVPN), or are there
reasons not to do that?

I have two LANs connected with routing (i.  e. tun) with only one
OpenVPN process running on either side, works for me (on SUSE Linux

> But when I ping host to host -- from to
> (ie. it has to come from LAN to Router, then over openvpn,
> then encrypted to the far router and out to the LAN there),
> something wierd happens. The packet disappears!

> Another observation : very similar ... lets ping directly from
> the router to the host on the other LAN, but with different
> source address (which also means the ping goes out on the
> other tun).
> On Router-America:
> ping  as well as,
> ping -I tun1  -- goes out on tun1, replies come on tun1, and works.
> ping -I tun0  -- goes out on tun0, replies come on tun0, ... 
>   ... but, never deliver from tun0 to the locally running ping process!!
> Is the kernel eating up the packet?

Perhaps - to defang packets with forged source address, the kernel drops
them if they are coming in via the wrong interface. The Linux
terminology is "martian", like this:

kernel: martian source from, on dev eth1

There are sysctls to enable source route filtering - check
net.ipv4.conf.*.log_martians if logging is enabled at all. The sample
message was captured when OpenVPN hadn't noticed some link change.
Restarting OpenVPN cured them in my case.

Matthias Andree
OpenVPN mailing lists