[TriLUG] OpenVPN bridge-mode question

Aaron S. Joyner aaron at joyner.ws
Wed Jun 21 11:19:06 EDT 2006


Brian Henning wrote:

> Hiya Gang,
>   Yous guys have been tremendously helpful (just like always) with my
> recent other inquiries, so I thought I might try my luck with this one
> too.  (I posted it to openvpn-users a few days ago, and no one
> ventured a reply)
>
> I have a machine running OpenVPN that has two NICs in it.  For
> argument's sake, we'll say eth0 connects to a LAN with a
> 192.168.10.0/24 subnet, and eth1 connects to a separate LAN with a
> 192.168.20.0/24 subnet.  Both subnets have their own public gateways,
> on different ISPs.  All of the servers I need to reach reside on
> .10.0/24.
>
> OpenVPN is configured to bind to all addresses (0.0.0.0) and hand out
> addresses in the 192.168.10.200 - .240 range.
>
> If I configure my bridge device (br0) to bridge my tap device (tap0)
> to the NIC on .10.0/24 (eth0), and bring inbound VPN connections in on
> the same interface (via the gateway on .10), everything works as
> expected.
>
> However...
>
> If I bring an inbound VPN connection via the NIC on .20.0/24 (eth1)
> with everything else above being the same, VPN negotiation never
> finishes and the OpenVPN server logs get a bunch of "no route to host"
> messages.
>
> My understanding of routing is still pretty cloudy at best..  and I
> have some vague instinct that "this makes sense, really" but can't
> clear it up in my mind.  I really need to make this work, though; I
> need VPN traffic itself to move in and out through eth1, but have it
> able to communicate with the subnet on eth0.  I also want to stick
> with bridging, if at all possible.
>
> Hopefully my verbal description is clear enough..  I'll sketch out a
> picture of the layout if necessary.
>
> Thanks in advance!
>
> ~Brian
>
This is a routing problem, not an OpenVPN problem.  You have traffic
coming in on eth1 from hosts not directly on the 192.168.0.20/24
subnet.  When your box attempts to respond to that traffic, it uses the
192.168.0.X source IP address, consults the default gateway for how to
route to the remote IP address, and sends the traffic out eth0 via the
default gateway.  Then one of two things happens.  If you're behind NAT,
the NAT gateway upstream of eth0 may NAT (depending on if it has
restrictions on what it will NAT for) your packet with it's external IP
address, then the remote end will receive but ignore your response
because it came from the wrong IP address (not the IP it was talking to,
which is associated with the eth1 network).  Alternately, if there's no
NAT involved and your subnets above are directly connected to say, cable
modem and dsl, then you'll be responding with the right source address
as far as the remote end is concerned, it won't get nat'd, but your
provider's not going to let you send outbound traffic with a source
address not from their network, so one of their routers along the way
will drop your packet.

I don't have time for a full description of how to use iptables rules to
solve this problem (gotta get out the door), but google around or check
the trilug archives for how to handle having two gateways and responding
via the right interface.  The fast and dirty version goes something like
this:
ip rule add from 192.168.20.X table 200
ip route add default gw 192.168.20.Y table 200

where X is your IP, Y is your default gw out eth1.

Good luck, let us know how it goes,
Aaron S. Joyner




More information about the TriLUG mailing list