-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Sunday, 3 July 2016 11:19 AM To: MikroTik Public <public@talk.mikrotik.com.au> Subject: [MT-AU Public] quetion re dual VPNs
I'm still playing with AWS Hardware VPN :-)
An AWS Hardware VPN is actually two VPNs; their idea seems to be that if one fails the other will still be there. The two VPNs terminate at different endpoints at the AWS end, but at the same endpoint on the MikroTik.
Apparently in order to support route-based VPNs, AWS also provides "inside addresses", a pair for each VPN. The actual traffic to AWS has to be routed via the inside address at the AWS end.
MikroTik has a bug in that it will not allow two IPsec policies that cover
same traffic. If you set up two VPNs and want to send the same traffic over both - which is what AWS expects you to do - one of the policies will be flagged "invalid".
My workaround is to set up one policy for (say) 192.168.100.0/24 for one VPN, then two others for the other VPN, with each covering half the desired range:
VPN1: 192.168.100.0/24
VPN2: 192.168.100.0/25 192.168.100.128/25
In order to send traffic to the right place, I also have two routes, one sending 192.168.100/24 via one inside address, the other sending the same traffic via the other inside address.
This is all working fine (though I suppose I can't use 192.168.100.127 or 192.168.100.128). If I manually disable either VPN, traffic keeps going on
Apologies for not answering your question directly {I admit to not taking the time your question deserves to fully comprehend all the implications of your report :-} I've received previous reports that one effective way to achieve what I assume to be your objective here, is to build a RouterOS VM inside your AWS cloud so that all you need is one public address to land on it then you have all of the routerOS VPN capabilities you need at both ends. Then your other VMS only need to live on your AWS virtual LAN and use RouterOS as boundary router and firewall. Although it does require buying another VM, the resource requirements are not large and usually not significant additional cost for all but the smallest AWS implementations. Regarding your question about routerOS end of your current setup, the resulting behaviour will depend on how you set up routes to the tunnel endpoints - if there are static routes in there, then so long as they will become inactive when the vpns fail (i.e. use 'check-gateway = ping' or 'check-gateway=arp') then you should be able to implement a routing policy that will automatically apply when the VPNs are active and fall back when they are offline. It the potentially failed gateway is not local to the router in question, then netwatch script is the right solution to deal with that too - either down and interface (or disable IP address) to cause a neighboring router to force a route to become invalid, or just change a relevant route entry. It is hard to decide exactly which way to go without full understanding of how it all goes together (maybe some diagrams showing relevant interfaces and addresses might help to clarify ;) but in the end, it is reasonable to expect that routerOS will almost certainly offer the right tools to implement something that does the job needed :) Cheers! Mike. the the
other - eventually, though it can take a few tens of seconds to reestablish while dead peer detection does its thing.
Now to my questions at last :-)
I can't test a VPN failure, because I can't drop either VPN at the ASW end. If one of the two VPNs did fail, what would happen? Will the MikroTik figure it out and not try to send packets up the dead one? Do I need to run netwatch and fiddle with the route metrics?
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160
GPG fingerprint: 6D59 8AE6 810D 44E3 7626 7040 4DD6 F89F 3053 4774 Old fingerprint: 9DCA 0903 BCBD 0647 BCCC 2FA7 A35C 57A1 ACF9 00BB
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au