[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bridging problems after Upgrade to Lenny



On Mon, Feb 23, 2009 at 01:25:30PM +0100, Udo Hortian wrote:
> Hello all,
> 
> I subscribed newly to this list, since I got an bridging problem
> after an upgrade from Debian etch to Debian lenny (before
> everything worked fine).
> 
> The situation is as follows:
> 
> # brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.000347729835       no              eth0
>                                                         tap0
> 
> tap0 is associated with an OpenVPN tunnel.
> 
> The strange thing now is the following:
> 
> Packets from eth0 to IP addresses within tap0 pass the bridge and reach
> the destination (the other side of the OpenVPN tunnel).
> 
> But packets from the other side of the OpenVPN tunnel do not reach
> destinations behind eth0. I think this is not an OpenVPN problem, since
> I can see packets, as described here, using "tcpdump -i tap0" and also
> using "tcpdump -i br0". But I do not see them using "tcpdump -i eth0".
> 
> The only thing which happens is that there are sometimes packets like
> this on eth0: "igmp v3 report, 1 group record(s)" (from tcpdump) with
> source address the one from the OpenVPN client. I do now know where
> these packets come from.
> 
> There is no firewall activated.
> 
> A few information about my system:
> - Debian lenny
> - Linux 2.6.18-6-686 (Debian Kernel from etch, I had problems booting the
> newer one from lenny)
> - bridge-utils 1.4-5
> 
> Any ideas what might be the reason for this and how to solve it?
I found the problem:

There was a config line

push "route 10.0.0.0 255.255.255.0"

in the OpenVPN configuration. This caused dos routing table entries at
the client side (the other side of the OpenVPN tunnel):

route -n
10.0.0.0        10.0.0.1        255.255.255.0   UG    0      0        0 tap0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tap0
[...]

Since we do bridging we do not want the route containing the gateway
10.0.0.1 (which is the OpenVPN Server running the bridge).

Deleting this route solves the problem and deleting the line mentioned
above in the configuration file solves the problem (without it, this
route entry will not be generated).

It suppose this route is not created by the OpenVPN package of Debian
etch.

Udo


Reply to: