Site-to-site IPSec tunnel with NATing host address

In the fourth part of the Mikrotik IPSec series, we will cover the scenario when we need to establish IPSec tunnel between two sites and at the same time to provide an alternative (NAT) address for the host. This scenario brings a new level of mayhem to our scenario.

You can expect such the same scenario whenever you need to work with restricted sites (like banks) or when the address space will not fit in your plans. In such case, you need to assign alternate addresses to the hosts involved in this solution.

Although this process sounds very complicated, it just requires a few more steps than the common site-to-site IPSec tunnel. The main difference is that we need to first apply a network address translation over the original host’s address.

clip_image002

As you can see, we will change the IP addresses of the mail server on the Contoso side and the FabrikaM server on the Fabrikam side. They will use addresses from the 192.18.0.0/24 and 192.19.0.0/24 network ranges.

I must make a note here. If you check my presentation from the MUM Serbia 2016, you will see that I swapped the second and third octets. Alas, those addresses are public and those mentioned in this document are intended for network testing.

To make this post shorter and easier to read, I will demonstrate the configuration process for one side. The other side will be configured in the same way. We just need to change a few parameters, like the peer IP address. In addition, you can find the download link for the demo scripts at the bottom of the post.

In the event that there is something important that we need to perform on both sides, I will highlight that part and provide you with both configurations. For those readers who don’t feel comfortable with this article, I would recommend to check the post about Mikrotik IPSec theory.

 

Important steps

Therefore, this scenario requires the following steps:

  1. Add DST-NAT rule for all hosts that will be covered with this IPSec tunnel
  2. Add SRC-NAT rule for all hosts that will be covered with this IPSec tunnel
  3. Configure the IPSec Peer
  4. Configure the IPSec Proposal
  5. Configure the IPSec Policy

As we can see from this short list, we have two additional steps over the previous scenario. How will this impact the IPSec configuration document? We need to enter NATed address for the host or network range into the appropriate field inside the Policies section.

clip_image004

Of course, this transformation will cover the Contoso side. We need to define the exact NAT addresses for every host on the FabrikaM side. However, this will be very similar to the NAT transformation for the e-mail server.

Be careful with the FabrikaM side. We will perform NAT over the FabrikaM server’s IP address. We will change the source IP address 192.0.2.10 to 192.19.0.10. This transformation will be valid only for communication with the network range 192.18.0.0/24.

In general, we must define 1:1 NAT rules for every single host that will use this tunnel. These rules must be at the top of the list of the NAT rules. This applies to both sides.

In case you have a communication problem, you should check these rules for NAT transformation. They are in IP > Firewall > NAT.

 

Define NAT rules

We need to define two things:

  • Bypassing the masquerade rule(s)
  • Pair of the source and destination NAT rules per every host

Here is the screenshot summarizing our settings. This one applies to the Contoso side.

clip_image005

The settings on the FabirkaM side are similar. We just need to reverse the source and destination addresses in the first rule. Other rules are related to the local IP address and appropriate NAT address for every host. In our example, these addresses are 192.0.2.10 and 192.19.0.10 respectively.

The first rule forcing bypass of all other NAT rules for the IP addresses is used here. We will place such rules at the top of the list. We can allow a whole network range. This rule is just bypassing the NAT. It won’t affect other processes.

It’s very important to define the correct rules for the incoming (DST) and outgoing (SRC) NAT processing. It’s not important which rule will be first. I first will define the DST-NAT rule. We must place these rules after the bypassing rules and before the masquerade rules.

We add a new rule for the incoming or destination (DST) NAT. On the Contoso side, we will publish the e-mail server under an alternative address. We need to choose the chain (dstnat) and destination IP address. As the published address is the NATed address of the server, we need to type that address here – 192.18.0.12.

clip_image006

Now, we populate the Action tab. We want to perform the DST NAT and we need to enter the real IP address where the packets should be sent. We should specify here the real IP address – 198.51.100.12.

clip_image007

We will similarly configure the outgoing NAT rule. We will specify the origin address that should activate this rule – 198.51.100.12. This is the real IP address of the server.

clip_image008

On the Action tab, we will choose the srcnat chain and provide the virtual, NATed, address for this host – 192.18.0.12.

clip_image009

We will perform all these steps for every host (in most cases servers) we need to include in this traffic. This means, if we want to allow communication between the workstation FabrikaM WS02 and the e-mail server, we need to define the appropriate NAT rule for that workstation.

In case that we want (or need) to force this NATed communication only for a single subnet and, at the same time, to communicate with other partners with original IPs, we should modify our NAT rules. This can be configured on the General tab.

Although I didn’t do that in this demonstration, we can add the IP address or whole network range. We should define the source address for the DST-NAT. Then that address will be the destination address in the SRC-NAT rule. In our case, we will enter the whole destination subnet range – 192.19.0.0/24.

Then we will mark that this rule will be activated only when we need to communicate with a host from that range. Otherwise, other rules will be used. Those other rules can be different NAT rules, IPSec policies or traffic routing rules, so it is important to define this correctly.

 

Define IPSec peer

This part is the same as in the previous post. In case you are just expanding on the previous scenario, you can skip this part as the IKE phase is already defined.

We will explain the Contoso side. The Fabrikam side is the same, we just need to change the IP address of the peer. All other settings must be the same.

We can see from the picture above and the example IPSec configuration document that the public IP address of the FabrikaM router is 203.0.113.29. We can see all the other settings in the named IPSec doc on the link above. However, you are free to alter these parameters if you like. In that case, you must alter them on the both sides.

clip_image010

When you configure another side of the IPSec tunnel, you want the routers to establish a connection. We can see this in the IP > IPSec > Remote Peers. Here is screenshot from the Fabrikam router.

clip_image011

 

Define IPSec proposal

We should always define a new proposal set for every new IPSec partner. This is the set of transformations rules for the end-point communications. Later, if we need to alter or update any of these rules, we can, without disturbing other partners and communications.

This step is the same as in previous scenario. In the event that you already completed the previous scenario, you do not need to add anything. For the new environment, we should make the new one.

clip_image012

 

Define the interesting traffic

We’re now on the step that make the difference between this and the previous scenario. We need to configure the NATed network ranges instead of the real LAN ranges.

As the rules are very similar and we just need to swap the IP addresses for the source and destination networks, I will show you the first screenshot from the Contoso side and the second from the FabrikaM side.

We need to add one or more policies in the same way as in the previous post. Keep in mind that we are working with NAT here. Therefore, we must specify the NAT ranges.

clip_image013

In the General tab we need to specify the IPs that will bring the tunnel up. There is no specific reason to use a single IP address here. It’s more convenient to use the whole range.

This first screenshot is from the Contoso router. We should reverse the IP ranges for the FabrikaM side.

clip_image014

The Action tab is from the FabrikaM router. Again, we will reverse the addresses for the Contoso side and choose the FabrikaM proposal.

clip_image015

 

Dude, where is my tunnel?

In case two hosts (servers) use IP addresses for their communication, the tunnel will arise now. Traffic will be passing as NAT and as NATed through IPSec tunnel.

However, if we are using server names (FQDN or DNS hosts names), we need to do one more thing. I missed this part on the presentation and later I demonstrated it during the troubleshooting skills session.

I wrote a small script on the FabrikaM server that sends an e-mail every 10 minutes. In the body of the message is just the date and time. Nothing special, but very handy to prove that this works. At the beginning of the script, I specified that the router should perform the resolution of the DNS name to IP address.

Our e-mail server is mail.contoso.com. In the main DNS server (located in MegaISP router) I defined the IP address 198.51.100.12. Now, all the other routers are using this DNS for their operations. I will manually execute the script.

clip_image016

We will check the tunnel. There are no SA associations.

clip_image017

As you can see from the previous screenshot, the IP address is wrong. We will check the local DNS cache on the FabrikaM router.

clip_image018

As we can see, the DNS service has the wrong IP in the cache. We should define the static IP address for this server. We should do this for every address that will be affected by the NAT process.

clip_image019

We will execute the script again. We should now see the correct IP address.

clip_image020

We used the correct IP address and the tunnel is running.

clip_image021

We can also check the e-mail from the client inside the Contoso network.

 

The command line scripts

We can configure all those settings from the command line. Many users will find this method more convenient. In addition, using the command line can help us to reduce configuration errors. Even more, the configuration dialog for Peers is extensive in RouterOS 6.35.

For your convenience, I have uploaded a text file with the scripts.

dl_button_img2

If you’re following this article in series, you can skip the parts that have been previously defined. You can also delete all previous settings and start from the scratch.

I didn’t cover the situation of limiting traffic to a specific network. The alternate commands for the Contoso side are here:

0 chain=dstnat action=dst-nat to-addresses=198.51.100.12 src-address=192.19.0.0/24 dst-address=192.18.0.12 log=no log-prefix=""
1 chain=srcnat action=src-nat to-addresses=192.18.0.12 src-address=198.51.100.12 dst-address=192.19.0.0/24 log=no log-prefix=""

You can use these scripts to simulate the same scenario or try your own. I encourage you during this exercise to try to change parameters and see the results. This is the best way to learn it.

Stay tuned.

Advertisements

One thought on “Site-to-site IPSec tunnel with NATing host address

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s