Virtual Private Network, VPN, allows encrypted communicated between two local area network over the public internet. Its importance in the networking industry can not be overemphasized as most cooperate organisations depend on it to get their jobs. In this post, I will explain one of the problems users face while configuring site-to-site VPN and how it can be resolved.
One of the major causes of site-to-site VPN authentication issues is the network address translation (NAT). When NAT is not properly configured on a gateway, vpn connection from a device behind it will not be established. This is because in the VPN policy, known as IKE phase1, the public IP addresses of the remote VPN device has been statically entered. This IP is also entered in IKE phase2 as the remote peer IP. What this mean is that the VPN gateway should negotiate authentication from that IP. Upon successful authentication, it should also negotiate data encryption with the device assigned the said IP when certain traffics (based on configured access-list) are identified.
The problem comes in when NAT is not properly configured on a gateway device placed in front of the VPN router to except the public IP on the VPN router from NAT. This problem, most of the times, is caused by ISPs. When the VPN IP is not excepted from NAT, the IP in the VPN authentication request sent to the remote end will be different from what the remote router has been configured to expect.
Resolving this problem can the easy when discovered to be NAT related. First, user must ensure that the public IP addresses configured on the VPN gateways are reachable from each other and that the authentication methods specified on the VPN gateways are the same. Click here for how to set up site-to-site ipsec vpn using the Cisco packet Tracer. If confirmed okay, user should proceed to check the NAT rule configured on the router, in this case ISP1 and ISP2 routers.
This problem is common on Mikrotik routers mostly because of the feature that allows users to choose the out interface as the only determining factors for traffics to be masqueraded. When the NAT rule is configured for everything leaving the WAN interface, it affects the VPN connections as IP on the ISP router’s IP is now included in the authentication request instead of the IP on the VPN gateway. As a result of this, the authentication fails because the packet is sourced from a different IP instead of the already configured IP.
To resolve this issue on Mikrotik, simply edit the NAT rule by excluding the public subnet of the VPN gateway from the NAT rule. See below:
/ip firewall nat add chain=srcnat action=masquerade src-address=!18.104.22.168/30 log=no
The exclamation mark in front of the public subnet ensures that traffics sourced from all IP addresses except the public subnet will have their source IP addresses changed to the IP on the WAN interface on the router. So instead of using the in-interface or out-interface as a factor for NAT, configure rules similar to the one above, especially when you have a VPN gateway behind your router.
You may also like: how to configure GRE tunnel between Cisco and Mikrotik routers
On Cisco routers, we usually use the access-list to match the source IP addresses to be translated as their packets exit the router. This has also be found to pose serious issues to site-to-site vpn authentication. Because access-lists have implicit deny rules at the end of all permit statements, many tend to think that by permitting only the private IPs, the router will automatically exclude the public IPs behind the router from being translated. Well, this has been found not to be true as VPN authentication issues have most times been traced to such configurations.
When an access-list is configured for NAT on a Cisco router, users must statically deny the IP address of the VPN gateway behind the router from being included. See sample command below:
TimiGate(config)#ip access-list extended NAT
TimiGate(config-ext-nacl)#deny ip host 22.214.171.124 any
TimiGate(config-ext-nacl)#permit ip 192.168.10.0 0.0.0.255 any
The second line in the access-list excepts the public IP on the VPN gateway from NAT. This must be done on both ISP routers to allow vpn authentication to be successful.