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

Re: [Openvpn-users] Basic bridging concept questions


  • Subject: Re: [Openvpn-users] Basic bridging concept questions
  • From: Whit Blauvelt <whit@xxxxxxxxxxxxx>
  • Date: Mon, 24 Jan 2005 10:44:36 -0500

Mathias,

Thanks so much for your quick and full response. 

On Mon, Jan 24, 2005 at 03:11:26AM +0100, Mathias Sundman wrote:

> >My first question is: The docs at bridge.sourceforge.net assume that all
> >you're trying to run is a bridge, rather than combining the bridging with
> >other functions on the same box and interfaces. So I'm unclear whether I
> >need a separate internal-facing NIC for the bridge, or whether a single
> >internal NIC is enough. The internal NIC currently has one or more IPs in
> >the 192.168.1.x range (one of those being the gateway to the external net
> >for the internal machines). It needs to maintain those. Can it be the
> >bridge device at the same time?
> 
> Yes. The most usual setup, I'd say is like that. You have OpenVPN on your 
> normal default gateway, so if you're using TAP, then it will be both 
> bridging your OpenVPN connections and routing your normal traffic to/from 
> internet.

This is encouraging, but I'm still not picturing fully if it allows what I
should do. Box 1 at present has its inward-facing NIC (eth0) assigned two
IPs, say 192.168.1.1 and 192.168.1.2, while Box 2 has eth0 assigned
192.168.1.3. 192.168.1.1 is the gateway for the internal net. If Box 1 goes
down then Box 2 also asigns 192.168.1.1 to itself to take over as the main
router. This is all with iproute2.

But it's Box 2 that I want to have handling the OpenVPN, both because of the
load issue - likely will have to run OpenVPN in TCP mode as well being, of
course, promiscuous - and because Box 1 is too important as a production
system to experiment with for this. OpenVPN and the default gateway will
only coincide if one box has failed.

> Begin your start-up scripts by setting up a bridge (br0) and include both 
> tap0 and eth0 (? your local interface) in it. Then assign your local 
> interface to br0 instead of eth0.

Maybe what I need to find is a diagram of the relation of br0, tap0 and eth0
from the standpoint of the kernel and iptables and iproute2. If I'm reading
the "sample-script/bridge-start" script right, eth0 is assigned to br0, then
tap0 is assigned to br0, then an IP is assigned to br0 (rather than eth0 in
normal usage). Meanwhile the kernel has already assigned one of the NICs to
eth0, so br0 inherits that NIC.

So do I have this right? Does the relationship go from the standard

kernel -> eth0 -> IP(s)

to

kernel -> br0 -> eth0
              -> tap0

with the IPs assigned at the br0 level and inherited by eth0 and tap0? So
when iproute2 is adding IP addresses to interfaces it should be working with
br0 ("ip addr add x.x.x.x dev br0 brd x.x.x.x"), and when iproute2 is
setting up routing for it should be ... what? I always do best with a
flow chart that shows the underlying concepts. So I'm looking at the LARTC
HOWTO (http://lartc.org/lartc.html#LARTC.BRIDGING) - nope, not much help. 

So let's see, what I want from OpenVPN is:

Remote client -> OpenVPN_port on eth1 or eth2 -> OpenVPN in user space ->
tap0 -> br0 -> internal NIC/IP -> box in internal LAN (with packet origin
appearing to be OpenVPN-assigned internal IP).

and then when the box in internal LAN responds, the NIC, being promiscuous,
will see the OpenVPN-assigned internal IP and then route it back to the
remote client. So br0 is presenting everything on the LAN to tap0, and tap0
is only responding to packets it recognizes as being in the address range
it's responsible for?

Meanwhile, if the box in internal LAN wants to address the OpenVPN box
itself, it uses any IP assigned to br0 and those packets are treated
according to the iptables rules for eth0? And if the OpenVPN box is also
acting as the Internet gateway, using that internal br0 IP likewise passes
through iproute2 rules and routes and firewall rules that specify eth0 in
the normal way ... or do they need to mention br0?

If the remote client should or should not have the capability to connect
directly to the OpenVPN box itself, where does that fit in the scheme? 

> Then treat br0 as your normal local interface, and it will route just as 
> usual between br0 and your external interface.

If anyone knows of a good diagram of these relations, I'd love to see it!

Whit

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users