Short Notes for Cisco 3850-24T IOS XE Upgrade & Stack Configuration

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)

Mikrotik Exemption Rules for IPSEC Tunnels

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:

• 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