[TriLUG] OpenVPN bridge-mode question

[Brian Henning]

Erhhh..  I'm still missing something.  Why should it matter which 
interface the encapsulated VPN packet comes in on?  I would expect 
(through my limited understanding) that any packet destined for port 
1154 coming in on any interface to which the OpenVPN process is bound 
(in this case, any interface) would get handed to the OpenVPN process, 
and its responses head back out whichever interface handles the "From" 
of the VPN packet.  It seems like the VPN part should be transparent, 
and as long as the TAP is bridged to the right private interface (such 
that local and remote TAPs are on the same subnet) the public interfaces 
in between shouldn't matter..  Such that:

[              Remote              ]
|                                  |
| --- TAP: 192.168.10.200 -------- |
| [        OpenVPN client        ] |
[------- Public interface ---------]
        {              }
        { teh intarweb }
        {              }
[------- Public interface ethX ----]
| [        OpenVPN server        ] |  <- OpenVPN host
[ --- TAP/eth1: 192.168.10.125 --- ]
        |                     |
        | 192.168.10.0/24 net |
        |                     |
        |      etc.           |


..  Perhaps what I should be doing at this point is experimenting with a 
routed VPN instead of a bridged VPN.  The bridging aspect of all of this 
is just giving me a headache!

Further input and correction is still quite welcome!

Cheers,
~Brian




<snip>
 > Aaron wrote:
 >
> 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
> 

-- 
----------------
Brian A. Henning
strutmasters.com
336.597.2397x238
----------------