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 the 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 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
-----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
On Sun, 2016-07-03 at 14:03 +1000, Mike Everest wrote:
Apologies for not answering your question directly
No apology necessary - others may well be interested in how to talk to AWS with a MikroTik. MikroTik could help by permitting multiple IPsec policies to cover the same ranges, but apparently that's remained a bug (or a limitation at best) since at least 2011 :-(
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.
Not quite what I'm aiming for. I'm trying to use a MikroTik as the local end of an AWS Hardware VPN: See this link for what I'm talking about: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html Basically you can extend your network directly into AWS - in my case into a VPC that has no public IP addresses at all (except on the outside of a VPG of course). And no NAT. I'll go cogitate on the rest of your answer (re routes) now. 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
Hi!
MikroTik could help by permitting multiple IPsec policies to cover the same ranges, but apparently that's remained a bug (or a limitation at best) since at least 2011 :-(
Not sure I would agree with characterisation of this as a 'bug' - I'd call it more of a 'limitation' since support of multiple tunnels between the same two endpoint addresses is probably more of an /extension/ to base IPSEC functionality than an explicit part of the protocol itself :-}
I'm trying to use a MikroTik as the local end of an AWS Hardware VPN: See this link for what I'm talking about:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html
So I looked at the docs, and the issue is different than what I initially understood - I thought that you needed to make two tunnels between the same peer endpoints, but really it's two remote peers, but you need the same /policy/ on each. So routerOS 'priority' attribute is supposed to be the way to support that, and YES, it doesn't seem to work like expected ;) However, I think I found a work-around. When I made the policies slightly different, they appeared to both come up OK. I did it by making two minor changes to the 'duplicate' policy: 1. made the source subnet on one policy larger (i.e. instead of just 192.168.0.0/24, I made it 192.168.0.0/23) and 2. made the IPSEC protocols on one of them 'esp' and 'ah&esp' on the other. Both peers came online, and SAs all set up OK. I could ping between the subnets, and when I kill one of them, 'backup' seemed to carry on the vpn. Needs some further testing, but initial checks came up OK. Have you raised this question with MT direct yet? If not, I'm going to ask them about it myself as I'm interested to know whether they consider it expected behaviour! ;) Cheers! Mike.
Basically you can extend your network directly into AWS - in my case into a VPC that has no public IP addresses at all (except on the outside of a VPG of course). And no NAT.
I'll go cogitate on the rest of your answer (re routes) now.
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
On Sun, 2016-07-03 at 16:15 +1000, Mike Everest wrote:
Not sure I would agree with characterisation of this as a 'bug' - I'd call it more of a 'limitation'
Oh, alright :-)
However, I think I found a work-around. When I made the policies slightly different, they appeared to both come up OK. I did it by making two minor changes to the 'duplicate' policy:
Thanks heaps for taking such an active interest! I'll try it out myself on my test AWS VPN, but did you have to make both changes, or would either do? And did you have to alter the IPsec protocol on the other end as well? If the second answer is "yes" then it won;t work, as there is no way to alter the AWS end. It is what it is. Changing the network size UP is possibly better than my choice of DOWN because it doesn't exclude two addresses from the middle. I'm not sure of the implications around broadcast addresses or the effects on BGP (which is the alternative to static routing) but I will give it a go.
Have you raised this question with MT direct yet? If not, I'm going to ask them about it myself as I'm interested to know whether they consider it expected behaviour! ;)
From my reading of numerous articles on the subject, it has definitely been raised with them. Can't hurt to raise it again.
The obvious alternative would be for them to add route-based IPsec; currently they support only policy-based IPsec (as far as I can tell - do enlighten me if they already support it!). That alternative would likely be a much bigger job though. I've blogged my efforts so far; any corrections or suggestions welcome: http://biplane.com.au/blog/?p=406 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
On Sun, 2016-07-03 at 16:50 +1000, Karl Auer wrote:
I'll try it out myself on my test AWS VPN, but did you have to make both changes, or would either do? And did you have to alter the IPsec protocol on the other end as well? If the second answer is "yes" then it won;t work, as there is no way to alter the AWS end. It is what it is.
Tried it out; using a supernet worked on its own. Changing the IPsec protocol prevented either of the policies from being flagged "invalid", but did not actually work. I wondered if I could fiddle with the IP protocols to make the policies "different" enough for RouterOS to let them co-exist. I tried it with three separate policies (for UDP, TCP and ICMP), but it didn't seem to work, though no policies were flagged "invalid". 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
Hi Thoughts that came to mind. Buy abother mikrotik ! What about a virtual machine on the mikrotik - or maybe 2 1 for each tunnel and then use bgp/ospf or routing protoclol of choice Vm's will get you around the 1 path per ipsec per device. A -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Sunday, 3 July 2016 2:21 PM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] quetion re dual VPNs On Sun, 2016-07-03 at 14:03 +1000, Mike Everest wrote:
Apologies for not answering your question directly
No apology necessary - others may well be interested in how to talk to AWS with a MikroTik. MikroTik could help by permitting multiple IPsec policies to cover the same ranges, but apparently that's remained a bug (or a limitation at best) since at least 2011 :-(
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.
Not quite what I'm aiming for. I'm trying to use a MikroTik as the local end of an AWS Hardware VPN: See this link for what I'm talking about: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html Basically you can extend your network directly into AWS - in my case into a VPC that has no public IP addresses at all (except on the outside of a VPG of course). And no NAT. I'll go cogitate on the rest of your answer (re routes) now. 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
On Sun, 2016-07-03 at 23:51 +0000, Alex Samad - Yieldbroker wrote:
Buy another mikrotik !
An AWS Hardware VPN is actually two IPsec tunnels; they terminate on different IP addresses at the AWS end, but on the same address at the customer end.
What about a virtual machine on the mikrotik - or maybe 2 1 for each tunnel and then use bgp/ospf or routing protoclol of choice
Ooh. That sounds interesting. Don't know anything about VMs on the MikroTik. How does that work? And can they share an IP address on an interface?
Vm's will get you around the 1 path per ipsec per device.
Yes - provided they can both have the same address on the same interface. That sounds dubious to me, but I'm ready - nay, eager! - to be amazed. In the meantime I've had another thought (untested). I wonder whether I can have two proposals, identical but with different names, and whether that would differentiate the second VPN enough for the MikroTik. But if different peers don't differentiate the policies enough, I suspect different proposals won't either. Peers and proposals are sort of on the "wrong end" of the deal - they don't help choose packets, they just help choose where and how. 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
Oh, the same address might be an issue. You could use NAT on the ipsec end point aslong as the source address is different.. I'm afraid my knowledge of vm's in mik is rather limited - read but not tried ... A -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Monday, 4 July 2016 10:22 AM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] quetion re dual VPNs On Sun, 2016-07-03 at 23:51 +0000, Alex Samad - Yieldbroker wrote:
Buy another mikrotik !
An AWS Hardware VPN is actually two IPsec tunnels; they terminate on different IP addresses at the AWS end, but on the same address at the customer end.
What about a virtual machine on the mikrotik - or maybe 2 1 for each tunnel and then use bgp/ospf or routing protoclol of choice
Ooh. That sounds interesting. Don't know anything about VMs on the MikroTik. How does that work? And can they share an IP address on an interface?
Vm's will get you around the 1 path per ipsec per device.
Yes - provided they can both have the same address on the same interface. That sounds dubious to me, but I'm ready - nay, eager! - to be amazed. In the meantime I've had another thought (untested). I wonder whether I can have two proposals, identical but with different names, and whether that would differentiate the second VPN enough for the MikroTik. But if different peers don't differentiate the policies enough, I suspect different proposals won't either. Peers and proposals are sort of on the "wrong end" of the deal - they don't help choose packets, they just help choose where and how. 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
I've played with them a little (I assume by VM's you mean MetaRouter), but haven't found them overly useful, as they saturate the CPU on the device very quickly. That said, my only hardware which supports it is my CRS109's. Just booting a metarouter on the CRS109 pins the CPU to 100% for 60 seconds, then more than 10mbps through the VM keeps it at the 100%, and makes things very laggy.. On 4 July 2016 at 10:31, Alex Samad - Yieldbroker < Alex.Samad@yieldbroker.com> wrote:
Oh, the same address might be an issue. You could use NAT on the ipsec end point aslong as the source address is different..
I'm afraid my knowledge of vm's in mik is rather limited - read but not tried ...
A
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Monday, 4 July 2016 10:22 AM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] quetion re dual VPNs
On Sun, 2016-07-03 at 23:51 +0000, Alex Samad - Yieldbroker wrote:
Buy another mikrotik !
An AWS Hardware VPN is actually two IPsec tunnels; they terminate on different IP addresses at the AWS end, but on the same address at the customer end.
What about a virtual machine on the mikrotik - or maybe 2 1 for each tunnel and then use bgp/ospf or routing protoclol of choice
Ooh. That sounds interesting. Don't know anything about VMs on the MikroTik. How does that work? And can they share an IP address on an interface?
Vm's will get you around the 1 path per ipsec per device.
Yes - provided they can both have the same address on the same interface. That sounds dubious to me, but I'm ready - nay, eager! - to be amazed.
In the meantime I've had another thought (untested). I wonder whether I can have two proposals, identical but with different names, and whether that would differentiate the second VPN enough for the MikroTik. But if different peers don't differentiate the policies enough, I suspect different proposals won't either. Peers and proposals are sort of on the "wrong end" of the deal - they don't help choose packets, they just help choose where and how.
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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-- Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of thunder. We danced among the lightning bolts, and tore the world asunder
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Damien Gardner Jnr Sent: Monday, 4 July 2016 10:36 AM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] quetion re dual VPNs
I've played with them a little (I assume by VM's you mean MetaRouter), but haven't found them overly useful, as they saturate the CPU on the device very quickly. That said, my only hardware which supports it is my CRS109's. Just booting a metarouter on the CRS109 pins the CPU to 100% for 60 seconds, then more than 10mbps through the VM keeps it at the 100%, and makes things very laggy..
On 4 July 2016 at 10:31, Alex Samad - Yieldbroker < Alex.Samad@yieldbroker.com> wrote:
Oh, the same address might be an issue. You could use NAT on the ipsec end point aslong as the source address is different..
I'm afraid my knowledge of vm's in mik is rather limited - read but not tried ...
A
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Monday, 4 July 2016 10:22 AM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] quetion re dual VPNs
On Sun, 2016-07-03 at 23:51 +0000, Alex Samad - Yieldbroker wrote:
Buy another mikrotik !
An AWS Hardware VPN is actually two IPsec tunnels; they terminate on different IP addresses at the AWS end, but on the same address at the customer end.
What about a virtual machine on the mikrotik - or maybe 2 1 for each tunnel and then use bgp/ospf or routing protoclol of choice
Ooh. That sounds interesting. Don't know anything about VMs on the MikroTik. How does that work? And can they share an IP address on an interface?
Vm's will get you around the 1 path per ipsec per device.
Yes - provided they can both have the same address on the same interface. That sounds dubious to me, but I'm ready - nay, eager! - to be amazed.
In the meantime I've had another thought (untested). I wonder whether I can have two proposals, identical but with different names, and whether that would differentiate the second VPN enough for the MikroTik. But if different peers don't differentiate the policies enough, I suspect different proposals won't either. Peers and proposals are sort of on the "wrong end" of the deal - they don't help choose packets, they just help choose where and how.
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
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
--
Damien Gardner Jnr VK2TDG. Dip EE. GradIEAust rendrag@rendrag.net - http://www.rendrag.net/ -- We rode on the winds of the rising storm, We ran to the sounds of
RB850Gx2 is the usual choice for running metarouters ;) thunder.
We danced among the lightning bolts, and tore the world asunder _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Karl Auer Sent: Monday, 4 July 2016 10:22 AM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] quetion re dual VPNs
On Sun, 2016-07-03 at 23:51 +0000, Alex Samad - Yieldbroker wrote:
Buy another mikrotik !
An AWS Hardware VPN is actually two IPsec tunnels; they terminate on different IP addresses at the AWS end, but on the same address at the customer end.
What about a virtual machine on the mikrotik - or maybe 2 1 for each tunnel and then use bgp/ospf or routing protoclol of choice
Ooh. That sounds interesting. Don't know anything about VMs on the MikroTik. How does that work? And can they share an IP address on an interface?
Vm's will get you around the 1 path per ipsec per device.
Yes - provided they can both have the same address on the same interface. That sounds dubious to me, but I'm ready - nay, eager! - to be amazed.
In the meantime I've had another thought (untested). I wonder whether I can have two proposals, identical but with different names, and whether that would differentiate the second VPN enough for the MikroTik. But if different peers don't differentiate the policies enough, I suspect different
My reading of the AWS docs suggest that the second VPN is /optional/ anyhow. So maybe the way to approach would be to set up ipsec to the primary remote address, and configure the second one but leave the policy disabled (you can still leave the peer active) Then use netwatch on the primary address to disble the active and enable the stand-by if that primary address goes offline for any reason. Cheers! Mike. proposals
won't either. Peers and proposals are sort of on the "wrong end" of the deal - they don't help choose packets, they just help choose where and how.
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
participants (4)
-
Alex Samad - Yieldbroker -
Damien Gardner Jnr -
Karl Auer -
Mike Everest