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
----------------
--
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/
