Thanks for all the help and apologies for not replying.

It took a LOT of work to get this working, but we managed it.

I'll paste my instructions below after anonymizing them.

Check Point BGP VTI VPN Tunnel Run Book

1. Make a new VPN tunnel in AWS

We cannot use the old VPN tunnels as they do not support BGP.

Make new VPN tunnels, using BGP, and using the same Transit Gateway and Customer Gateway as the old tunnel uses.

Use the same name as the old tunnel, but with “-bgp” appended to the name.

We are doing this through Click Ops. this is not too difficult for people with basic AWS training.

Lastly, once the tunnel is built, download the configuration with the button, choose “Check Point” and R80.10+

2. Build Tunnels in Check Point

Prerequisites

Removing External IP from inside the VPN tunnel

Gateway Cluster properties -> Network Management -> VPN Domain

Tick "Exclude Gateway’s external IP from the VPN Domain"

Making sure we don’t break any other VPN tunnels

Set specific VPN domain we are working on to "Empty_Group" so that other VPN tunnels are not affected.

Disable Anti-Spoofing for packets just from “AWS_ ACCOUNTS-PLUS-VTI_PEERS”

We don’t want to turn on Anti-Spoofing for all external traffic, just for AWS traffic & all virtual tunnel peers.

The object already exists and can be used for all Gateway clusters, but will need the virtual tunnel peers added for each Gateway cluster we do.

PreRequisite Planning

Add New AWS Tunnels (Interoperable Devices)

The old names we use are too long, they get cut off in one of the fields in Smart Console, this makes them both the “same” name which does not work.

Work out new objects names from the old ones. For example AWS-TRANSIT-CORE-EU-WEST1-OFFICE3-TUNNEL2 turns into to AWS-TRANSIT-CORE-EU-WEST2-O3-T1.

This will allow each name to stay unique in the field where it is too long.

For now, just write this down, we don’t need to make this change in Smart Console as we will actually make these objects in CLISH

Tasks in WebUI / CLISH

Build VTI Interfaces (CLISH)

NOTE! Using objects we named in the previous step.

Download the instructions from the AWS website.

Find the tunnel instruction commands and modify them.

      add vpn tunnel 1 type numbered local 169.xx.xx.170 remote 169.xx.xx.169 peer AWS_Tunnel1

      set interface vpnt1 state on

      set interface vpnt1 mtu 1399

      save config

              TO

      add vpn tunnel 1 type numbered local 169.xx.xx.1 remote 169.xx.xx.169 peer AWS-TRANSIT-CORE-EU-WEST1- S0-T1

      set interface vpnt1 state on

      set interface vpnt1 mtu 1399

      save config

Note, not only has the name changed, but we have also put in a “fake” IP. This is because the cluster object uses the real, .170 IP. We use “1” as our IP as it helps us work out which tunnel this IP is linked to and is different enough from the real one that you cannot accidentally mistake it for one of the real IPs.

Don’t forget there are 4 tunnels in total, 1 for each Firewall / Gateway, plus 2 for the 2 tunnels, makes a total of 4. Make sure you make all four in CLISH (two per gateway).

Configure VPN Object

Use the same VPN object as the old tunnels, this is not an issue as nothing is changed until we publish the changes.

Add new objects we just made to Satellite objects locations. (This removes the old tunnels from use, and lines up our new one.)

Set VPN Domain to “EmptyGroup” if not already.

Turned off MEP

Turned off NAT

Set Phase 1 & 2 timers to 60 mins (known to resolve some bugs)

All other settings can stay the same.

Configure Gateway Network Properties

Go into the Gateway cluster’s properties, then go to Network Management.

Click “Get Interfaces” -> “Without Topology”

You will see the two new VPN Tunnels appear (only 1 in the picture below)

You must now configure the correct cluster IP. Double click on “vpnt1” in the list.

You will see the two “fake” IPs we created earlier, and an empty field for the clustered IP.

Place the real IP (.170 in our earlier example) into the IPv4 box.

Do the same for “VPNT2” with the correct IP for that tunnel.

Build NAT Rules

We need to build custom NAT rules because the clustered IP without custom NAT will stop BGP traffic being replied to.

We need to build two sets of NAT Rules.

• VPN Tunnel only rules
• All other traffic rules (IE turn NAT off)

VPN Tunnel NAT Rules

The VPN tunnel needs to translate the two “fake” IPs (Source) into the cluster IP (translated source) so that the return traffic has a real IP address to be sent to.

Make all the objects listed above, then create these rules.

• AWS-Tunnel1-VTI-IP-Local-Nodes = The “fake” IPs we made earlier (.1 for Gateway 1 & .2 for Gateway 2 in our example)
• AWS-Tunnel1_VTI_Remote = the AWS real IP (.169 in our example)
• AWS-VTI-Tunnel1-IP-Local-VIP = the real Check Point side IP (.170 in our example)

Then make the objects again for Tunnel 2 (see pic above for the correct layout)

Next we make the “Do not NAT” NAT. This turns off NAT for other traffic which goes down the tunnel we are making.

This rule is pretty simple, it takes all local traffic, and if it’s moving to AWS it keeps all NAT info to original, IE no NAT. The rule below is the same, but in reverse.

Adding in the Rules to the Policy

We need to make two major changes to the policy. We need to add in BGP rules, and remove the VPN setting for traffic we plan to move down the tunnel (or convert the VPN settings to be the same as the BGP Out rule)

As you can see, the rules allow BGP traffic from the Local tunnel addresses, to the remote tunnel addresses. The VPN settings are more unique though.

For the VPN settings we need to use “Directional Match Condition” VPN, we cannot use traditional VPN. If we do, it will not work. (A different daemon will process it, and it will not be pushed down the tunnel)

Hope this helps others.