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 -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
