Mikrotik IPSEC Tunel with SAP HEC !

---

Following post contains information on how we configured IPSEC tunnel using our mikrotik router (CCR1036) with SAP HANA (High-performance Analytic Appliance) HEC (Hana Enterprice [private] Cloud). I am documenting some basic ideas along with configuration codes for myself, because soon we will be migrating from our decade old mikrotik router to Fortigate NGFW.

HEC is an infrastructure-as-a-service tool that enables companies to run SAP-based operations in a hosted environment. HANA Enterprise Cloud (HEC) was introduced to tr+ansform, migrate and operate mission critical applications in a private cloud environment.

For SAP HEC , We opted for Policy based VPN tunnel (wiht PSK) which was relatively simpler to configure & doesnt requires BGP/ASN which is required in route based vpn option. SAP team shared one sheet with us asking for ipsec related parameters, our local ip subnet, & one subnet for sap end virutal instance that we will be accessing at there end & our wan IP. they shared IPSEC related parameters as per below,

• Phase 1: IKEv2-AES256-SHA384-DHgroup20
• Phase 2: AES256-SHA256-PFSgroup20
• Pre-Shared Key (PSK)
• SAP peer IP address: 1.2.3.4

Unlike other types of VPN’s like pptp/etc, Policy-based IPSec doesn’t have routes. With the Mikrotik, IPSec does not create a virtual interface & you don’t need to add any routes. The packets head for the default route, but the IPSec policy matches the source/dst subnets, and route where it it needs to !

• All VPN/IPSEC parameters must meet exact at both ends i.e HEC & customer end. In beginning, SAP HEC end made some mistakes like incorrect pre-shared key (PSK) was shared with us, our wan ip was not added in there vpn server allowed hosts which cane establish vpn connectivity with there servers. In such cases your local partner ROLE is very important & unfortunatley we didn’t get any active network related support from our local technology parter ! 

Example used in this post for illustration purposes:

• IPSEC paramenters as metnioned above,
• SAP HEC VPN Server IP: 1.2.3.4
• Source LAN IP Pools: 10.1.1.0/24 , 172.16.1.0/24 (our office local subnet, it must be allowed on remote vpn server)
• Destination SAP HEC Private IP Pool on which SAP HEC is hosted: 192.168.50.0/24 (We asked them to use this pool at there end)

---

Mikrotik SAP HEC IPSEC Workingn Config Code:

All the configuration regaridng IPSEC parameters must match exactly at both ends (vendor & customer router) else tunnel will not happen. (In some cases it may be required to request for vendor remote assistance & show them your settings so that they can tune it at there end for matching)

# Add IPSEC profile
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha384 name="SAP HEC IPSEC PROFILE" nat-traversal=no

# Add remote IPSEC server IP address with IKEv2 Support
/ip ipsec peer
add address=1.2.3.4/32 exchange-mode=ike2 name="SAP HEC IPSEC PEER" profile="SAP HEC IPSEC PROFILE"

#Add IPSEC proposal
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1d name="SAP HEC IPSEC Proposal" pfs-group=modp2048
# Disable default proposal, as not required
set [ find default=yes ] disabled=yes enc-algorithms=aes-128-cbc

# Add IPSEC pre-shared KEY (provided by SAP or you can also create your own key & shar eit to SAP so that they can set it at there end for your IPSEC profile)
/ip ipsec identity
add peer="SAP HEC IPSEC PEER" secret="STRONG-PRE-SHAREd-KEY"

# Add IPSEC Policies, providing information on what local IP subnet will be able to communicate with remote IP pool, (must be allowed at SAP end as well)
/ip ipsec policy
add dst-address=192.168.50.0/24 peer="SAP HEC IPSEC PEER" proposal="SAP HEC IPSEC Proposal" src-address=10.1.1.0/8 tunnel=yes level=unique
add dst-address=192.168.50.0/24 peer="SAP HEC IPSEC PEER" proposal="SAP HEC IPSEC Proposal" src-address=172.16.1.0/24 tunnel=yes level=unique

# Disable default IPSEC policy, as not required
set 3 disabled=yes

Mikrotik Exemption Rules for IPSEC Tunnels

#Bypass PVN pool from other chains

/ip firewall raw
add action=accept chain=prerouting dst-address=192.168.50.0/24

#Below may not be require if you add it in RAW, but documenting it as we made it work with different scenarios
/ip firewall nat add chain=srcnat action=accept place-before=0 src-address=10.1.0.0/24 dst-address=192.168.50.0/24
/ip firewall nat add chain=srcnat action=accept place-before=0 src-address=172.16.1.0/24 dst-address=192.168.50.0/24

# Exempt SAP HEC Pool from mikrotik local NAT rule
/ip firewall nat
add action=src-nat chain=srcnat comment="Default_NAT_Rule_for_Allowed_Users with Exempting IPSEC Tunnel" dst-address=!192.168.50.0/24 out-interface=WAN1 src-address-list=Net_Allowed_users action=masquerade

---

TIPS:

Following are few tips that I learned in a hard way !

• If you have multiple local subnets, you need to create POLICIES accordingly , as shown in the example in this guide (code example). Level of every policy should be set “unique” instead of “required”.
  Also these pools must be allowed at remote server. In our case , only one pool was allowed at remote server in beginning & this created many days in wall banging efforts, as a workaround we created a src-nat rule to NAT our other local subnets to src-nat via allowed pool ! example:

/ip firewall nat
add action=src-nat chain=srcnat comment="Workaround - Jugaaroo Rule to make IPSEC Tunnel Work / SJZ" disabled=no dst-address=192.168.50.0/24 src-address=172.16.1.0/24 to-addresses=\
x.x.x.x (my router lan subnet ip which is allowed on remote site)

• All VPN/IPSEC parameters must meet exact at both ends i.e HEC & customer end. In beginning, SAP HEC end made some mistakes like incorrect pre-shared key (PSK) was shared with us, our wan ip was not added in there vpn server allowed hosts that cane stablish vpn connectivity with there servers. In such cases your local partner ROLE is very important & unfortunatley we didn’t get any active network related support from our local technology parter ! 
• You also need to exclude the IPSec subnets from the masquerade natting rule. Ensure you EXCLUDE the detination SAP HEC Pool from *any* NATTING rule (show in code example)
• If you clients can ping the remote servers, but your mikrotik itself cannot, then You can fix it either using srcnat, or with fake routes where you set pref-src. It doesn’t matter where such route points to, it won’t be actually used. It can be e.g. empty bridge.  Route with pref-src is better, because it works for everything. E.g. if you do traceroute from one LAN to another, there will by default be a hole where remote router should be.
• Seond option, If you are pinging from the Mikrotik itself, make sure you set src-address so that it matches the policy example
  ping 192.168.50.10  src=10.1.1.1 (10.x is IP from allowed pool)
• Try disabling and re-enabling the identity, as adding policies on the fly behaves funny in some RouterOS versions.

IPsec has as two modes, one is the Tunnel mode and the second is the Transport Mode.

Tunnel mode is used in site to site VPNs, between Gateways in simple words and is the default mode while Transport mode is used for client to site VPNs or end to end, between a computer and a Gateway…

Now, the Tunnel mode adds a New IP Header in front of the IP header of the originating packet…
In transport mode no new IP header is added, so the IP stays the same… Unless NAT is perforfmed…

If you have transport mode IPSec (e.g. for L2TP/IPSec), decrypted packet (L2TP) will have same addresses as encrypted (unless it’s changed by NAT). If you have tunnel mode IPSec (e.g. LAN to LAN tunnel), decrypted packet will have the source address of remote device in LAN (it it came from it) and destination address will be device on local LAN, while encrypted packets will have remote router as source and local router as destination.

IPsec policy kicks in after all other packet processing, including routing and NAT, has been done and the packet is just about to be sent out via an interface. So some route must match the dst-address of the packet, but it is not important which one in particular it is. And to be recognized by the policy, the packets’ src address must not be changed by src-nat if the route sends them out via WAN with src-nat; on the other hand, you may want to src-nat them intentionally in some scenarios.

---

References: Mikrotik Forum

 

Regard’s
Syed Jahanzaib