|
|
Hi Leonard Isham,
First of all I'd like to extend our thanks to the developers of OpenVPN - a
fantastic solution, which is a pleasure to work with.
Secondly I'd like to ask a question. Our VPN network is set up as follows:
Network A
|
Node A
/ \
/ \
/ \
/ \
Node B --------- Node C
| |
Network B Network C
All links between nodes (all Linux hosts) are OpenVPN links over the Internet
through a router with mapped ports for servers, as you'd expect.
We're using bridged ethernet to accomplish network bridging, so each node has a
bridge device consisting of the node's ethernet connection and both VPN TAP
devices on that node.
All hosts are on the class-A 10.*.*.* subnet, with IP conflicts resolved by
allocating a class-B address space (10.x.*.*) to each network. DHCP queries
have naturally been blocked over the VPN by using ebtables.
In order to avoid loops, etc., we've enabled STP on our VPN nodes.
The upshot of all this is the following: we now have a fully functioning,
pretty rock-solid implementation.
Sadly we have a niggle (there's always one). Because we're using STP, one node
is always elected as the root node. Lets's say node A is elected. Now all
communications from C -> B must go through A. This is slower than the ideal
situation, where comms from C -> B (and back) would go through the C -> B VPN
link.
Our internet links are relatively slow (ADSL), with upload limits of about 256K.
Obviously avoiding indirectly routing packets if possible is desirable.
We understand this is how STP works, but we'd like to put the question to the
OpenVPN users community (and the developers, if they're listening in). How
would you go about making sure the /optimal/ route to the packet destination is
always taken?
I have the same problem, but with more than 2 hosts. I want broadcasts,
cause many games doesn't allow internet game without key. Network
browsing and many other things works easier (static ip if you have
dynamic ip at home, ...).
Effectively it is easy: Our upstream is limited, so we can't do a full
mesh. A better resolution is a single server, which is acting as
switch. The only thing that talks against that is, that packets from
Client A to Client B goes over this Switching VPN-Server and only now
to Client B. I found a fine resolution cause all my clients are
connected to the same peering point here in munich. I installed my vpn
switching server on a provider which has a direct connection to this
peering point. The roundtrip-time (a ping) from there to the clients is
less than 10 ms. So the clients are connected to eachother with about
20ms, which is perfectly fine.
I don't think that there is a better resolution in my situation. ... if
the vpn server would work, as I wrote in my last mail "OpenVPN makes
VPN-Server unreachable via TCP/UDP (not ping) if a client connects".
Regards,
Markus Mueller
|
|