In 2021, the organization decided to migrate SAP workloads to AWS to enjoy the benefits provided by the cloud. At the same time, we will be step closer to modernizing the applications. In on-prem, we were using Site2Site VPN with SAP. We planned to use a similar solution in AWS using “AWS Site 2 Site VPN”.

https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html

Problem

We opened an OSS message with SAP asking VPN form(as per SAP Note 28976 and 486688) that needs to be filled for IPSec VPN and informing them about our plans to use AWS S2S VPN for SAPRouter. We received the below response from SAP support.

Please be aware that we have several customers tried to set up VPN IPSEC connections with AWS VPN end point and they have not been successful. What we recommend in this case is to set up a SNC (SECURE NETWORK COMMUNICATION) connection. 

We went back to the drawing board analyzing the risks associated with making SAPRouter public and encrypting traffic over SNC. Infosec team also concurred that opening SAPRouter over the public internet will increase the surface area for potential threats/attacks. Additionally, we use many different types of connections/protocols(WTS/SSH/R3/HTTP/JDBC etc) to open system access to SAP support and SNC can only encrypt R3 connections.

We consulted our migration partner about the usage of AWS S2S VPN and the feedback we received from them was not positive either. Most customers either go with “SNC over Internet” option or continue their Onprem SAPRouter Infrastructure(S2S VPN).

All the online resources also suggested for SNC over the internet(if SAPRouter is on cloud infrastructure)

Testing AWS S2S VPN

As opening SAPRouter to public internet doesn’t seem to be a good option for us, we determined to proceed with testing AWS S2S VPN(against all odds). We updated OSS message asking about supported routing protocols(BGP or Static Routes) for IPSec tunnel, VPN peer IP. subnets to be included in encryption domain etc. We received below response on OSS messsage.

High Level Diagram for S2S VPN

Data at SAP side

Hostname SAProuter server————-> sapserv1

IP address SAProuter server———–> 194.x.x.x<-

Encryption Domain———————> 194.x.x.x/30 <-

IP address VPN gateway—————-> 194.y.y.y

We have completed the form shared by SAP and shared our details.

Data at Customer side

Hostname SAProuter server————-> xxxxxxxx.example.com

IP address SAProuter server———–> x.x.x.x

Encryption Domain———————> b.b.b.b/28

IP address VPN gateway—————-> 18.x.x.x(Tunnel-1) /34.y.y.y(Tunnel-2)

We decided to go with IKEv2 as IKEv1 will be phased out in near future(SAP Note 2800846)

IPSec options (select):

While filling out the details in the form we realized there is a problem with PH1 and PH2 lifetimes. SAP confirmed that the default can’t be changed on their end. This lead to another problem. In this scenario, even if we are successful to establish the tunnel, this will not be stable due to different lifetimes.

The Phase1 and Phase2 lifetimes are different on AWS as compared to SAP.

Phase1: AWS Default: 28800 sec  SAP’s Default: 86400 sec

Phase2: AWS Default: 3,600 sec SAP’s Default: 7200 sec

Workaround

To overcome this problem we decided to generate some interesting traffic over the tunnel periodically. We wrote a basic shell script to perform ping operations(ICMP traffic) and configured it in cron running every 15 mins. This will keep traffic flowing through the tunnel preventing it from dropping.

Additionally, SAP confirmed that they will not be configuring any backup tunnel if you are hosting a single SAPRouter. In essence, the Tunnel 2 option provided via AWS S2S will not be used.

Configuration of S2S VPN

Once you received peer IP(VPN Gateway IP on SAP side), please create a Customer Gateway and Virtual Private Gateway under VPC section.

Customer Gateway Created under VPC Section

Virtual Private Gateway Created under VPC

Proceed to create VPN.

Create VPN under VPC section

Once SAP made the configurations on their side(VPN Gateway), SAP support shared with us the pre-shared key via email in an encrypted document.

We authenticated the VPN tunnel using pre-shared key and we are ready to go.

Tunnel Status on AWS Console

Conclusion

Once the tunnel is up, we asked SAP support to test the connection to one SAP system(R3) and WTS(using NLS) hosted in DMZ. Additionally, we published metrics related to tunnel status, and data in/data out using AWS dashboards. With that, operations teams supporting internal systems get visibility.

The VPN is in use for more than a year now without any hassle.