How to resolve Site-to-Site VPN authentication issue on Mikrotik and Cisco routers

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

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.

Network Topology

site-to-site vpn connection
Image showing site-to-site VPN connection over the internet

Solution

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.

On Mikrotik

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=!187.255.252.116/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

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 187.255.252.116 any

TimiGate(config-ext-nacl)#permit ip 192.168.10.0 0.0.0.255 any

TimiGate(config-ext-nacl)#exit

TimiGate(config)#

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.

 

Spread the love

Timigate

Ashioma Michael, a BSc (Computer Science)., MTCNA, CCNA, and CCNP holder with many years of industry-proven experience in network design, implementation and optimization. He has tutored and guided many professionals towards obtaining their Cisco certifications. Mike works as a senior network engineer with one of the leading internet service providers in West Africa.

Leave a Reply

Your email address will not be published. Required fields are marked *