I’m a total noob on running the github files that I downloaded.
How am I going to run these files ( script )?
Did anybody managed to get GRE tunnels up on AWS CHR? They are dead which never happened in my long Mikrotik history.
I want to implement GRE over IPSEC.
With version 6.47 I think I got the IPsec to AWS figured out. The new ipsec commands are not (yet) in the documentation, I hope this is fixed soon.
I have to experiment more with this, but it is something to work on.
This seems to work:
/ip ipsec profile
add dh-group=modp1024 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-128 lifetime=8h name=aws-profile
/ip ipsec peer
add address=3.126.56.73/32 name=peer2 profile=aws-profile
add address=3.123.57.35/32 name=peer1 profile=aws-profile
/ip ipsec proposal
add enc-algorithms=aes-128-cbc lifetime=1h name=aws-proposal
/ip ipsec identity
add peer=peer1 secret=fWKxxxxxxxxxxxxxxxxxxxxxxxxxzQdK
add peer=peer2 secret=N8jxxxxxxxxxxxxxxxxxxxxxxxxxa6l6
/ip ipsec policy
add dst-address=169.254.127.189/32 peer=peer1 proposal=aws-proposal sa-dst-address=3.123.57.35 sa-src-address=x.x.x.x src-address=169.254.127.190/32 tunnel=yes
add dst-address=172.31.0.0/20 peer=peer1,peer2 proposal=aws-proposal sa-dst-address=3.126.56.73 sa-src-address=x.x.x.x src-address=x.x.x.x/24 tunnel=yes
add dst-address=169.254.204.165/32 peer=peer2 proposal=aws-proposal sa-dst-address=3.126.56.73 sa-src-address=x.x.x.x src-address=169.254.204.166/32 tunnel=yes
Nice!
In the rule with two peers, you are listing the sa-dst-address as for just one of the peers. Will that work with the second route as well?
Did you figure it out?
In fact, the sa-dst-address is inherited from the address of the active peer - you don’t need to enter it and it appears anyway. In the manual, it has been described as a Read Only parameter since quite some time ago; it can still be set but it is not necessary to set it (at least for tunnel mode SAs).
I was able to set up an AWS site to site VPN and get both required ipsec tunnels working following this procedure
https://medium.com/@autogun/aws-site-to-site-vpn-with-mikrotik-routeros-5977ca5e50ae
A few tips:
It only works on very recent firmware (6.48.1 for me).
Make sure in your BGP instances that the default ASN is set to the same as your AWS customer gateway, eg 65000. (this is not mentioned in the above link)
You might have to fiddle a little (enable +disable) the ipsec policies to get both tunnels up but once you get them up, they will stay up.
I can ssh fine between my local subnet (192.168.2.0/24) and my remote AWS VPC subnet (192.168.88.0/24) but since my remote VPC doesn’t have any internet gateway, I would like the remote subnet to to be able to access the internet through the vpn and my local subnet. Somehow that is not working, I have a feeling it has to do with the nat exemption rules but I don’t know how to modify the above procedure to get it working…
I am not a network expert and I am running a Mikrotik hAP ac² and configured AWS Site2Site VPN successfully.
Though sometimes (about once a month), the VPN stopps working, and i don’t know why.
I always need to restart, so that everything works again.
It would be very important to reduce downtimes and also to reduce manual actions.
Do you know where i can start? Also may an other hardware may solve this? Maybe also another brand of router?
Logging of the VPN operation would be a good start if you can notice the outage quickly enough or if you can connect a USB drive to the hAP ac²’s USB port. Sniffing of network traffic may be necessary if the above doesn’t reveal the issue, which may require external hardware.
What kind of VPN is it? Bare IPsec or something else? Posting an anonymized export of your configuration is the best answer.
As for other hardware or brand - the reason may be outside the hAP ac², and if it is inside, it still may be a software issue that can be fixed if reported to the manufacturer. On the other hand, changing the device is a relatively quick way to find out whether the cause is internal or external - if a different hardware running a different operating system doesn’t exhibit the same issue for three months, you can assume the issue was caused by the hAP ac².
I use hAP ac²s with IPsec at multiple places and have never suffered a VPN outage that would require a manual intervention to be resolved. But none of my setups has AWS at the remote side. And in more complex setups, where multiple devices at the same site use the same public IP addresses, some specific measures need to be taken so that restarts of individual routers wouldn’t affect re-establishment of the tunnels, but I guess that’s not your concern.
I’d appreciate clues on what’s wrong with my setup trying to utilize both tunnels between hardware Mikrotik 6.48.3 and AWS VPN in Dynamic routing setup (BGP) and having only random subset of my hosts being able to reach AWS side (tcpdump on AWS side shows it sends replies but my hosts don’t receive them when both tunnels are up, when only one tunnel is up all works perfectly but not BGP-redundant):
I’ve used a combination of these methods:
Sep 2020 https://medium.com/@autogun/aws-site-to-site-vpn-with-mikrotik-routeros-5977ca5e50ae
Mar 2018 https://kkc.github.io/2018/03/14/AWS-VPN-with-RouterBoard/
I have two test machines on Mikrotik side to reach AWS.
- It works when only one of 2 tunnels is up (the other one is deliberately down) for both for AWS- and Mikrotik-LAN both ways, but it’s not redundant and AWS keeps reminding about it.
- It doesn’t work when both tunnels are up, AWS console shows both as UP, 1 BGP ROUTES, and when I ping from Mikrotik LAN to AWS either of my machines randomly doesn’t receive responses from AWS. I see MKT route table showing all routes for both 169.254 AWS-side subnets:
/ip route print
...
4 ADb 10.14.0.0/22 169.254.222.5 20
5 Db 10.14.0.0/22 169.254.21.45 20
6 ADb 10.14.8.0/22 169.254.21.45 20
7 Db 10.14.8.0/22 169.254.222.5 20
tcpdump running on AWS side shows it receives all ICMP and sends responses back but I’m randomly not receiving the responses on the Mikrotik LAN machines side when both tunnels are up.
I’ve tried to have the 1/2 tunnels (10.8.8.0/24 is the whole - split to 0/25 and 128/25) like in the Medium article but it doesn’t help:
/ip ipsec policy add dst-address=<<<AWS-PRIVATE-SUBNET-1>>> peer=AWS-1 proposal=aws-proposal src-address=<<<FIRST-HALF-OF-MT-LAN-CIDR>> tunnel=yes
/ip ipsec policy add dst-address=<<<AWS-PRIVATE-SUBNET-1>>> peer=AWS-1 proposal=aws-proposal src-address=<<<SECOND-HALF-OF-MT-LAN-CIDR>>> tunnel=yes
I’ve also tried to set level=“unique” instead of “required” for multi-peer policies, and to change the order of peers, but it also didn’t help.
/ip ipsec policy add comment=aws-sandbox-1 dst-address=<<<AWS-PRIVATE-SUBNET-1>>> peer=AWS-1,AWS-2 proposal=aws-proposal src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> tunnel=yes
/ip ipsec policy add comment=aws-sandbox-1 dst-address=<<<AWS-PRIVATE-SUBNET-2>>> peer=AWS-1,AWS-2 proposal=aws-proposal src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> tunnel=yes
My config - some firewall input rules are excessive from the github link, 65000 is exactly the ASN I have set up for my CG on AWS side.
/ip ipsec profile add dh-group=modp1024 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-128 lifetime=8h name=aws-profile nat-traversal=no
/ip ipsec peer add address=<<<AWS-PUBLIC-IP-2>>> local-address=<<<MIKROTIK-PUBLIC-IP>>> name=AWS-2 profile=aws-profile
/ip ipsec peer add address=<<<AWS-PUBLIC-IP-1>>> local-address=<<<MIKROTIK-PUBLIC-IP>>> name=AWS-1 profile=aws-profile
/ip ipsec proposal add enc-algorithms=aes-128-cbc lifetime=1h name=aws-proposal
/routing bgp instance set default disabled=yes
/routing bgp instance add as=65000 client-to-client-reflection=no name=aws-vgw-1 redistribute-static=yes router-id=<<<169.254-MIKROTIK-SIDE-1>>>
/routing bgp instance add as=65000 client-to-client-reflection=no name=aws-vgw-2 redistribute-static=yes router-id=<<<169.254-MIKROTIK-SIDE-2>>>
/routing bgp network add network=<<<MIKROTIK-PRIVATE-SUBNET>>>
/routing bgp peer add comment=aws-sandbox-1 hold-time=30s instance=aws-vgw-1 keepalive-time=10s name=BGP-vpn-033cc6148d842ce4b-0 remote-address=<<<169.254-AWS-SIDE-1>>> route-reflect=yes
/routing bgp peer add comment=aws-sandbox-2 disabled=yes hold-time=30s instance=aws-vgw-2 keepalive-time=10s name=BGP-vpn-033cc6148d842ce4b-1 remote-address=<<<169.254-AWS-SIDE-2>>> route-reflect=yes
/ip firewall filter add action=accept chain=input comment=AWS dst-address=<<<169.254-MIKROTIK-SIDE-1>>> dst-port=179 protocol=tcp src-address=<<<169.254-AWS-SIDE-1>>>
/ip firewall filter add action=accept chain=input comment=AWS dst-address=<<<169.254-MIKROTIK-SIDE-2>>> dst-port=179 protocol=tcp src-address=<<<169.254-AWS-SIDE-2>>>
/ip firewall filter add action=accept chain=input comment=AWS dst-address=<<<MIKROTIK-PUBLIC-IP>>> in-interface=<<<MIKROTIK-PUBLIC-INTERFACE-NAME>>> protocol=ipsec-esp src-address=<<<AWS-PUBLIC-IP-1>>>
/ip firewall filter add action=accept chain=input comment=AWS dst-address=<<<MIKROTIK-PUBLIC-IP>>> dst-port=500 in-interface=<<<MIKROTIK-PUBLIC-INTERFACE-NAME>>> protocol=udp src-address=<<<AWS-PUBLIC-IP-1>>> src-port=500
/ip firewall filter add action=accept chain=input comment=AWS dst-address=<<<MIKROTIK-PUBLIC-IP>>> in-interface=<<<MIKROTIK-PUBLIC-INTERFACE-NAME>>> protocol=ipsec-esp src-address=<<<AWS-PUBLIC-IP-2>>>
/ip firewall filter add action=accept chain=input comment=AWS dst-address=<<<MIKROTIK-PUBLIC-IP>>> dst-port=500 in-interface=<<<MIKROTIK-PUBLIC-INTERFACE-NAME>>> protocol=udp src-address=<<<AWS-PUBLIC-IP-2>>> src-port=500
/ip firewall nat add action=accept chain=dstnat comment=AWS in-interface=<<<MIKROTIK-PUBLIC-INTERFACE-NAME>>> src-address=<<<AWS-PRIVATE-SUBNET-1>>>
/ip firewall nat add action=accept chain=srcnat comment=AWS dst-address=<<<AWS-PRIVATE-SUBNET-1>>> src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> to-addresses=<<<MIKROTIK-PRIVATE-SUBNET>>>
/ip firewall nat add action=accept chain=srcnat comment=AWS dst-address=<<<AWS-PRIVATE-SUBNET-2>>> src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> to-addresses=<<<MIKROTIK-PRIVATE-SUBNET>>>
/ip ipsec identity add peer=AWS-1 secret=<<<SECRET-1>>>
/ip ipsec identity add peer=AWS-2 secret=<<<SECRET-2>>>
/ip ipsec policy add comment=aws-sandbox-1 dst-address=<<<169.254-AWS-SIDE-1>>> peer=AWS-1 proposal=aws-proposal src-address=<<<169.254-MIKROTIK-SIDE-1>>> tunnel=yes
/ip ipsec policy add comment=aws-sandbox-2 disabled=yes dst-address=<<<AWS-PRIVATE-SUBNET-1>>> peer=AWS-2 proposal=aws-proposal src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> tunnel=yes
/ip ipsec policy add comment=aws-sandbox-1 dst-address=<<<AWS-PRIVATE-SUBNET-1>>> peer=AWS-1 proposal=aws-proposal src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> tunnel=yes
/ip ipsec policy add comment=aws-sandbox-2 disabled=yes dst-address=<<<AWS-PRIVATE-SUBNET-2>>> peer=AWS-2 proposal=aws-proposal src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> tunnel=yes
/ip ipsec policy add comment=aws-sandbox-1 dst-address=<<<AWS-PRIVATE-SUBNET-2>>> peer=AWS-1 proposal=aws-proposal src-address=<<<MIKROTIK-PRIVATE-SUBNET>>> tunnel=yes
/ip ipsec policy add comment=aws-sandbox-2 disabled=yes dst-address=<<<169.254-AWS-SIDE-2>>> peer=AWS-2 proposal=aws-proposal src-address=<<<169.254-MIKROTIK-SIDE-2>>> tunnel=yes
Did you try it with 6.49 also can you share the configuration once, as I am trying but not been able to do it on 6.49.1
First of all a HUGE THANK YOU to the post Author. I’ve be battling with AWS CCR2004 and v7.1.5 for a while and I finally got it to work after finding this post with BGP.
As mentioned however, we aren’t able to keep both tunnels UP. The first reason is because we can’t have two policies with the same Src./Dst. as mentioned by the author. The second thing, is that if you add 2 peers to a single Policy, it will fail because AWS only allow a single SA pair to be installed on the same tunnel.
AWS tunnels in order to become both online, they require the customer gateway to support Asymmetric Routing (http://forum.mikrotik.com/t/routeros-aws-vpn-asymmetric-routing-problem/156878/4). I’ve discussed a lot with their premier support and this is the only way to have redundancy with both tunnel AFAIK.
That being said, I see the tunnels UP and the BGP routes being propagated however, since the 0.0.0.0/0 → AWS policy is disabled deliberately on the second tunnel, I have a lot of packets lost when AWS decides to send the response on that tunnel. The same if the CCR decides to send packets thru that tunnel.
In other words, unless we have that missing policy added AND having the support to Asymmetric routing, we are not going to have the full redundancy provided by AWS VPNs. It is a shame that it isn’t supported on MikroTik Routers 
I hope some day they implement it. I moved away from Ubiquiti’s UDM-PRO exactly because of the lack of BGP and two-tunnel support but I guess I made the wrong decision…