-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 21/11/14 11:06, [email protected] wrote:
> And finally, the situation you draw, looks like your connection and
> a server at your HQ are a single-point-of-failure.
That's a really good point too!
If the branch offices needs to communicate between each other as well,
with my proposed suggestion you can as well add VPN tunnels in
parallel between each branch office. For example something like this:
<branch-lan-1: 192.168.10.0/24>
| +--------------------+
\----+ eth0: 192.168.10.1 |
| |
| [branch-1-gw] |
| | (HQ-VPN-1: 10.8.10.0/24)
| tun0: 10.8.10.2 +------------\
| tun1: 10.9.2.2 | | +-----------------+
+----+---------------+ | | [HQ-GW] |
| (HQ-VPN-2: ) | | |
| (10.8.20.0/24) \----+ tun0: 10.8.10.1 |
<branch-lan-2: > | /--------+ tun1: 10.8.20.1 |
<192.168.20.0/24> |*1 | /-----+ tun2: 10.8.30.1 |
| +----+---------------+ | | | |
| | tun1:10.9.2.1 | | | | |
| | | | | | |
| | [branch-2-gw] | | | | eth0:192.168.0.1|
| | | | | +----+------------+
| | tun0: 10.8.20.2 +--------/ | |
\-----------+ eth0: 192.168.20.1 | | |
| tun2:10.9.3.2 | | v
+----+---------------+ | <HQ-lan: >
| | < 192.168.0.1/24>
| |
| |
| |
|*2 |
+----+---------------+ |
| tun1:10.9.3.1 | |
| | |
| [branch-3-gw] | |
| | |
| tun0: 10.8.30.2 +-----------/
/------+ eth0: 192.168.30.1 | (HQ-VPN-3: 10.8.30.0/24)
| | |
| +--------------------+
|
<branch-lan-3: 192.168.30.0/24>
*1: branch-vpn-1-2: 10.9.2.0/24
client on branch-1-gw
server on branch-2-gw
*2: branch-vpn-2-3: 10.9.3.0/24
client on branch-2-gw
server on branch-3-gw
This is the core principle. You can also consider to one more
tunnels, between branch-lan-1 and branch-lan3 for an absolute
redundancy (that is, creating a branch-vpn-3-1). By also adding
routing metrics, the performance between branch-1 and branch-3 can
also be improved by adding this extra VPN tunnel.
However, the routing of such a net will not be too easy. And you will
need policy routing here ('ip rule' and 'ip route ... table ...'), to
ensure that traffic arriving on branch-vpn-1-2 also returns using the
same interface. Without having tested this, I'd presume you would
need such rules on all VPN servers/clients. Those far more
experienced in advanced routing setup can probably explain this far
better than I can.
The advantage of this setup is that you always have two routes
available to any of the other sites. So if one site fails/becomes
available it should be possible to get access to the rest of the sites
still being functional. And even if the one of the openvpn processes
on stops running on the HQ-GW box, the traffic can still flow through
to the HQ-lan via one of the other branch offices. And the same goes
for the branch offices as well.
But as I already said, this is an advanced setup which requires a very
good understanding of how network routing works and how to configure
it correctly. There are a lot of pitfalls and traps when setting up
such a network. But once you understand how routing works, setting it
up isn't illogical.
- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlRvJCwACgkQDC186MBRfrr2NgCfdoHeePXhzfKppUs9a3GJZR72
/c0AmgMGlCOUOY2tqLJqEZi3LKBMlNP5
=rJSf
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
