Udo Hortian
2009-Feb-22 12:32 UTC
[Bridge] Bridging problems after Upgrade to Debian Lenny
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 an 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 now firewall activated. Here are a few informations about my system: Debian lenny Linux 2.6.18-6-686 (Debian Kernel) bridge-utils 1.4-5 (Debian packet) Any ideas what might be the reason for this and how to solve it? Best regards Udo
Udo Hortian
2009-Feb-27 20:54 UTC
[Bridge] Bridging problems after Upgrade to Debian Lenny
On Sun, Feb 22, 2009 at 01:32:49PM +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 an 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 now firewall activated. > > Here are a few informations about my system: > Debian lenny > Linux 2.6.18-6-686 (Debian Kernel) > bridge-utils 1.4-5 (Debian packet) > > 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). Udo