Hi,
I'm trying to figure out a way to set up some redundancy in my freeswan
network. I have lots of remote sites with tunnels to my servers at a
colocation facility. If one of the remote machines goes down, it's not
that big of a deal, it's one customer down. But if the ipsec gateway at
the colo goes down, all the customers are down. As well as my company's
mail, web, etc. that's bad. heh.
This started out with trying to make the gateway at the colo be a bridge
and firewall and ipsec gateway, because i don't have control over my
routing there. Up to now i have been using the proxy_arp trick to get
around that, but since im about to replace that one machine with 2 (so i
can at least fail over by SSHing in and running a script on the second
box to take over the IPs of the 1st and enable proxy_arp), i decided to
look into bridging. Since "people" say proxy_arp is "bad".
Anyway, i got bridge+firewall+freeswan working, and in my reading of the
bridge docs, i learned of STP. This allows 2 bridges to be cabled in
parallel, and they negotiate with eachother to see which one will
bridge. If one goes down, the other takes over. All transparently.
This gave me the following idea: (forgive my crappy ASCII art)
REMOTE SITE(s)
____________
VPN left ipsec gateway / \
192.168.1.0/25---192.168.1.1/10.0.1.2< |
runs OSPF \ BIG |
| BAD |
/---- IPSEC tunnel 1 to .130 -------/ INTERNET |
/ |
| /
| ------- IPSEC tunnel 2 to .131 -------------
| /
| \ ipsec+bridge+firewall
| ---------------- |-192.168.0.130-|
| | \ __|__ __|__ VPN right
| | colo router >---| HUB | <STP> | HUB |----192.168.0.192/26
\ | .129 / --|-- --|-- each run OSPF
------------------- |-192.168.0.131-|
ipsec+bridge+firewall
COLOCATION FACILITY
my subnet is 192.168.0.128/25
The IPs depicted are of course not real, they are the ones im using for
the test setup i built here at home (yes, i have 6 machines piled up in
my living room with cables going all willy-nilly...the wife is not
pleased). However, they do reflect the real topology as far as
subnetting goes.
On the remote gateway, i thought it would be simple. Set up 2 tunnels,
and run zebra to do OSPF dynamic routing on them. If one went down,
zebra would detect it and start using the other one.
Part of the trick to getting the bridging to play nice with freeswan is
that the colo machines behind the firewall/bridge have to have the
bridge's IP as their gateway. So in my scenario, each of these machines
would also run a dynamic rounting daemon locally, which would choose
between 2 default routes out (.130 and .131). Win2k server has a routing
service, and the linux boxen would run zebra.
I suspect this second part, at the colo, would work. Turns out the
problem lies at the remote end, where i thought it would be easy. From
the ipsec_whack man page:
> When a routing is attempted for a connection, there must not already
> be a routing for a different connection with the same subnet but
> different interface or destination, or if there is, it must not be
> being used by an IPsec SA. Otherwise the attempt will fail
And sure enough, it does:
[root_at_router /etc]# ipsec auto --up routernet-to-bridgenet
104 "routernet-to-bridgenet" #3: STATE_MAIN_I1: initiate
106 "routernet-to-bridgenet" #3: STATE_MAIN_I2: sent MI2, expecting MR2
108 "routernet-to-bridgenet" #3: STATE_MAIN_I3: sent MI3, expecting MR3
004 "routernet-to-bridgenet" #3: STATE_MAIN_I4: ISAKMP SA established
112 "routernet-to-bridgenet" #4: STATE_QUICK_I1: initiate
003 "routernet-to-bridgenet" #4: cannot install eroute -- it is in use
for "routernet-to-bridge2net" #2
032 "routernet-to-bridgenet" #4: STATE_QUICK_I1: internal error
While composing this, i realized that even if i get around that, there
might be another problem....zebra probably cannot choose between
eroutes, only regular routes.
So. Now i guess my question is: does this give you experienced users or
the develpers any ideas on how to set up some redundancy?
PS: For those of you who may be intersted in the
bridge+firewall+freeswan setup, i'd be glad to help. However, there is a
caveat: the bridge_nf code (patches to netfilter to allow iptables
firewalling on a bridge) cannot firewall on -i ipsec0, only those that
are part of the bridge (eth0, eth1). The result is that there is no way
to block traffic on the bridge from either side of the VPN if its not
encrypted, because you have to firewall by IP, rather than just allowing
everything in and out of ipsec0. The upshot is that if the tunnel
somehow went down on both sides, things would go through in the clear.
Anyway, any ideas/insights/help would be appreciated :)
Jon Erdman
Progressive Practice, Inc.
http://www.progressivepractice.com/
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:18 CEST