IPSec tunnel to AWS

bonemancer · Tue Jun 14, 2022 1:15 pm

Hello to Everyone!

I am running CHR with 6.49.6 software installed.
At the moment trying to implement IPSec connection to AWS.

My LAN network: 192.168.7.0/24
AWS side network: 10.0.0.0/22
Tunnel networks are: 169.254.153.72/30, 169.254.158.28/30
AWS side WAN IPs: 3.69.17.65, 3.124.181.121
My IP is: A.B.C.D

The task is to configure two VPNs to AWS as it should be.

First of all I would like to say, that AWS Support gave info that IPSec policy should be 0.0.0.0/0 <-> 0.0.0.0/0 in order to cover Transform Set (TS) for LAN to LAN and Tunnel network communication.
The reason for that is: AWS supports only one TS per VPN and there is no way to use two TS.

At the moment I am using following configuration which works for LAN to LAN communication:

/ip address
add address=192.168.7.1/24 interface=ether2 network=192.168.7.0
add address=A.B.C.D/28 interface=ether1 network=A.B.C.E
add address=192.168.7.254 comment="LAN GW" interface=vrrp7 network=192.168.7.254
add address=169.254.153.74/30 interface=ether1 network=169.254.153.72
add address=169.254.158.30/30 interface=ether1 network=169.254.158.28

/ip firewall nat
add action=accept chain=srcnat comment="No NAT for VPN networks" dst-address=169.254.153.73 log=yes src-address=169.254.153.74
add action=accept chain=srcnat dst-address=169.254.158.29 log=yes src-address=169.254.158.30
add action=accept chain=srcnat dst-address=10.0.0.0/22 src-address=192.168.7.0/24
add action=src-nat chain=srcnat comment="LAN outside NAT to VRRP IP A.B.C.D" ipsec-policy=out,none out-interface=ether1 src-address=192.168.7.0/24 to-addresses=A.B.C.D

/ip ipsec policy group
add name=aws
/ip ipsec profile
add dh-group=modp2048 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=8h name=profile-aws-vpn nat-traversal=no prf-algorithm=sha256
/ip ipsec peer
add address=3.124.181.121/32 exchange-mode=ike2 local-address=A.B.C.D name=aws-tunnel-2 profile=profile-aws-vpn
add address=3.69.17.65/32 exchange-mode=ike2 local-address=A.B.C.D name=aws-tunnel-1 profile=profile-aws-vpn
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h name=ipsec-aws-vpn pfs-group=modp2048
/routing bgp instance
set default as=65000 router-id=169.254.153.74

/ip ipsec identity
add peer=aws-tunnel-1 policy-template-group=aws secret=<secret1>
add peer=aws-tunnel-2 policy-template-group=aws secret=<secret2>

/ip ipsec policy
set 0 dst-address=0.0.0.0/0 src-address=0.0.0.0/0
add dst-address=169.254.153.72/30 peer=aws-tunnel-1 proposal=ipsec-aws-vpn src-address=169.254.153.74/32 tunnel=yes
add dst-address=10.0.0.0/22 peer=aws-tunnel-1 proposal=ipsec-aws-vpn src-address=192.168.7.0/24 tunnel=yes
add dst-address=169.254.158.28/30 peer=aws-tunnel-2 proposal=ipsec-aws-vpn src-address=169.254.158.30/32 tunnel=yes
add dst-address=10.0.0.0/22 peer=aws-tunnel-2 proposal=ipsec-aws-vpn src-address=192.168.7.0/24 tunnel=yes

/routing bgp network
add network=192.168.7.0/24
/routing bgp peer
add hold-time=30s keepalive-time=10s name=BGP-vpn-04037c036d133df8d-0 remote-address=169.254.153.73
add hold-time=30s keepalive-time=10s name=BGP-vpn-04037c036d133df8d-1 remote-address=169.254.158.29

This configuration establishes one IPSec session 192.168.7.0/24 < > 10.0.0.0/22
Tunnel IPsec works with no phase 2 (logs show wrong TS errors)
And second 192.168.7.0/24 < > 10.0.0.0/22 Tunnel is inactive.

The question is:
how to change this configuration to use 0.0.0.0/0 <> 0.0.0.0/0 IPsec policy.
When I add such a policy router becomes inaccessible.
0.0.0.0/0 variant is as follows:

/ip ipsec policy
add action=none dst-address=192.168.7.0/24 src-address=0.0.0.0/0
add action=none dst-address=0.0.0.0/0 src-address=169.254.153.72/30
add disabled=yes dst-address=0.0.0.0/0 peer=aws-tunnel-1 proposal=ipsec-aws-vpn src-address=0.0.0.0/0 tunnel=yes

Please help.

bonemancer · Tue Jun 14, 2022 2:04 pm

What a great pity:
Here is information from following post:
viewtopic.php?p=922744&hilit=amazon#p922744

Links:
https://medium.com/@autogun/aws-site-to ... 77ca5e50ae
https://kkc.github.io/2018/03/14/AWS-VP ... uterBoard/

AWS tunnels in order to become both online, they require the customer gateway to support Asymmetric Routing. 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

Can someone please comment this?

sindy · Wed Jun 15, 2022 9:58 am

Can someone please comment this?

This is how bare IPsec is designed to work - for a given traffic selector, only one policy can be active at a time. It is even required that packets that reverse-match the traffic selector of an existing policy but did not come in via a security association linked to that policy were dropped. So it's not Mikrotik to blame about this.

There is a non-standard thing called VTI which goes against this idea - it negotiates a traffic selector between the peers at protocol level, but instead of using it to choose the traffic to be sent down the SA and to filter the received traffic, it creates a virtual interface like any other tunnel, so you can use normal routing tables to route the traffic to the tunnel and there is no filtering of received packets. And while many router and firewall vendors have implemented this, Mikrotik hasn't.

However, what might work for you is the Mikrotik's implementation of IPsec redundancy as introduced somewhere in 6.47.x(?), where you attach a policy to a pair of peers, and it is only actually negotiated with one of them at a time. So one of the peers at AWS would always see the tunnel as broken and thus it should not advertise itself to the hosts at the AWS side as a gateway towards the Mikrotik destinations.

I have no subscription with AWS so I could never test that with AWS, but it should not be a big deal for you as you've already got 95 % completed.

bonemancer · Wed Jun 15, 2022 10:19 am

Hello, Sindy

Thanks for Your deep explanation.

Perhaps issue is that other open source solutions (pfSense as an example) allow two tunnels to be established at a time and I can see that both tunnels are up on AWS console.
In addition if both tunnels are up I can see two BGP peers which send BGP updates and their prefixes.
So such implementation would be something that could be very needed.

My conversation with AWS Support still continues and if I get some information on this I will add to this post as I spent lots of time gathering information on RouterOS configuration.
Perhaps someone will google my post in the future and his life will be much easier.

sindy · Wed Jun 15, 2022 11:30 am

...
So such implementation would be something that could be very needed.

My suggestion was simply to try out what is available right now rather than dreaming what Mikrotik might change in future.

With VTI support at Mikrotik, nothing special would be required to make it work the way AWS has designed it. But people have been asking Mikrotik for VTI for years and nothing has happened yet.

It takes a few minutes to test the method I've suggested, and while it works a bit different than AWS has planned, it should still work well and provide redundancy.

IPSec tunnel to AWS

IPSec tunnel to AWS

Re: IPSec tunnel to AWS

Re: IPSec tunnel to AWS

Re: IPSec tunnel to AWS

Re: IPSec tunnel to AWS

Who is online