i tried this, and while routing does in fact work and failover if i
manually drop a route, i cannot get automatic failover to happen. with
ike in active mode i don't have problems with ipsec, but when putting
ike into dynamic (in order to enable DPD) i can't seem to get ipsec
up. is there another way to enable DPD?

going with gre/ospf, one link works just fine but never fails over to
the internet-based link - even though both links (gre0/gre1) show up
in the routing table. so i reconfigured ospf to only use gre1
(internet) and it doesn't work even when by itself - even though the
routes get propagated. if i disable ospf and manually add the routes,
the link works.

i'm losing hair here. any help would be GREATLY appreciated. configs follow:

"R" box:
------------
hostname.gre0:
10.200.244.233 10.200.244.234 netmask 0xffffffff link0 up
tunnel 10.200.244.246 10.200.48.254

hostname.gre1:
10.200.244.225 10.200.244.226 netmask 0xffffffff link0 up
tunnel r.pub.ip w.pub.ip

ospf.conf:
redistribute 192.168.5.0/24
redistribute static
redistribute connected
password="pttpthhh"
auth-md 1 $password
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
 interface gre0
 interface gre1
 interface vr0 { passive }
 interface vr1 { passive }
 interface vr2 { passive }
}

ipsec.conf:
ike esp transport from r.pub.ip to w.pub.ip
ike esp transport from 10.200.244.246 to 10.200.48.254

sysctl.conf:
...
net.inet.ip.forwarding=1
net.inet.gre.allow=1
net.inet.esp.enable=1
net.inet.ip.multipath=1


"W" box:
-------------
hostname.gre0:
10.200.244.234 10.200.244.233 netmask 0xffffffff link0 up
tunnel 10.200.48.254 10.200.244.246

hostname.gre1:
10.200.244.226 10.200.244.225 netmask 0xffffffff link0 up
tunnel w.pub.ip r.pub.ip

ospf.conf:
redistribute 10.200.0.0/16
redistribute 172.16.0.0/16
redistribute connected
redistribute static
password="pttpthhh"
auth-md 1 $password
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
 interface gre0
 interface gre1
 interface bnx0 { passive }
 interface bnx1 { passive }
 interface bnx3 { passive }
}

sysctl.conf:
...
net.inet.ip.forwarding=1
net.inet.gre.allow=1
net.inet.esp.enable=1
net.inet.ip.multipath=1


here's a horrible but fairly accurate map of the networks and their
connections (fixed width font helps here):

     --------------------{internet}-------------------
    |                                                |
r.pub.ip                                         w.pub.ip
(R)10.200.244.246 -- 10.200.244.241 (router) ... (router)
192.168.5.1                                    10.200.48.250
                                                     |
                                               10.200.48.245
                                                    (W)
                                               10.200.244.249
                                                     |
                                               10.200.244.254
                                                  (router)
                                        10.200.0.0/16 + 172.16.0.0/16


2009/12/11 Mitja Mu>enih <mi...@muzenic.net>:
> A simple trick to fail over two vpn connections (scenario #1) is if you use
> two slightly differently sized subnets as the remote end of the tunnel.
>
> Say your peer LAN is 192.168.1.0/24.
>
> Create a tunnel from $local_LAN to 192.168.1.0/24 over the preferred
> connection (MPLS in your case), and a second tunnel from $local_LAN to
> 192.168.0.0/16 over the backup connection. As long as the primary tunnel is
> up, the tighter network destination wins and the traffic to 192.168.1.0/24
> will flow over the primary tunnel. If that goes down, 192.168.0.0/16 will
> match too and the traffic will enter the backup connection. Use DPD to
> ensure prompt tunnel failure detection and you are golden.
>
> Last time I did this was with 3.9, but I don't see a reason why it wouldn't
> still work. I managed to failover in <5 seconds back then.
>
> Naturally feel free to do your testing before deploying. if this doesn't
> work, then you have to use gif(4) tunnel endpoints and a routing daemon
such
> as ospfd.
>
> As far as 2# is concerned, you _might_ get away with two gif(4)
encapsulated
> and encrypted tunnels, then trunk(4)ing the gif(4) interface pairs. I never
> tried that nor heard of anybody doing that.
>
> Mitja
>
>> -----Original Message-----
>> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
>> Dewey Hylton
>> Sent: Friday, December 11, 2009 10:40 PM
>> To: misc@openbsd.org
>> Subject: ipsec / trunk / failover
>>
>> hi all. i have two sites connected by a slow mpls connection, each
>> having faster connections to the internet. both are viewed as
>> untrusted, so site-to-site traffic flowing over either mpls or
>> internet needs to be encrypted.
>>
>> 1) my minimum requirement at this point is for an encrypted connection
>> over mpls, with an encrypted connection over internet as failover. i
>> know it seems backwards, but since the mpls connection is "guaranteed
>> bandwidth" management prefers it over the internet connection.
>>
>> 2) my optimum setup would be to use both connections in order to
>> improve bandwidth, and having the connection simply get slower if one
>> of the links goes down.
>>
>> i've already implemented ipsec tunnels in openbsd so i favor that
>> method, but am willing to go with openvpn if it proves to be more
>> beneficial. i am inexperienced with the rest of the equation, so have
>> plenty of questions and am in need of guidance.
>>
>> in order to achieve #1, it seems that i might be able to create two
>> ipsec tunnels, one mpls and one internet, and route traffic across
>> them via ospf. is that right? any pointers/corrections there?
>>
>> in order to achieve #2 ... could i create two ipsec tunnels and trunk
>> them? or could i create some kind of unencrypted tunnel over each
>> link, trunk them, and run ipsec on the trunk? if trunking is even
>> possible in either of these situations, how do i best utilize the
>> links (they are different speeds)?
>>
>> i believe i understand the purpose and rough workings of ospf/bgp/etc
>> but have no experience with them or with the gif/gre/tun devices.
>> suggestions/pointers/links/howtos will be greatly appreciated.

Reply via email to