In the fifth part of the IPSec series, we will cover the next common scenario in IPSec implementation. We will also be IPSec myth busters. Of course, there will be no spectacular explosions as in the TV show. Nevertheless, we will break the myth that IPSec tunnel cannot pass through the NAT.
Our scenario is very common in the world. We have a larger company, with one or more high-speed Internet links and public IP addresses assigned to them. On the other hand, we have a small company that wants to works almost without spending money. In addition, they want to reduce the operation costs in the wrong places.
Our scenario is like this:
I highlighted the most important part related to this scenario. Small company, named Trange Frange Comp (jargon in Serbian for something that is of low quality), leased grandma’s ADSL link speed of 4/1 Mbps for their main business Internet link. As Internet links cost some money, there are no redundant links.
They received ADSL CPE router from ISP. I used MikroTik RouterOS x86-v3.30 software router to simulate that piece of equipment. Although MikroTik RouterOS is very powerful and flexible software, we have used it here in the routing mode. It is possible to use it even as the network bridge and to simulate the ADSL modem device.
This means that our internal network for the Trange Frange Company (named as TFC in further text) will be NATing (hidden behind the NAT device). ADSL router connects to the PPPoE access server inside the ISP’s network. I will not discuss this mechanism in this post. However, we just reviled the subject for future articles.
PPPoE service uses dynamic allocation of addresses and some parts of the PPP protocol. This part of about dynamic address assignment is the most important here. We don’t know the public or at least an outer IP address assign to ADSL CPE router.
You can see that we’re just faced with two challenges. Our main router has the public IP and is connected with high-speed links. Our remote router is behind the NAT device with dynamic IP address. Woohoo!
If you remember the theory of the IPSec tunnels and the baseline scenario for the site-to-site tunnel, then you know that we need to know the addresses for both sides. Moreover, we don’t have the fixed IP address on the side of the smaller company. Fun is in the air!
Of course, we are establishing IPSec tunnel for the end users in the TFC’s local network. They will access the Contoso Web server. Yup, grandpa DOS VM with EZ-NOS WWW server – only 4 MB of RAM and 10 MB of virtual hard disk. This is simulation of a CRM or collaboration server, which will never be publish to the Internet.
Checking the connection
We should have the basic connection between the remote network and the Contoso router. We will check this by using the command ping and/or traceroute. We should do this from both the router and workstation. At this stage, the Web server is not accessible.
As the first step, we will check whether the ADSL customer is connected to the PPPoE server. This process is automatic and the client will connect as soon as the RouterOS boot.
Our remote company has “Internet” access. Now we will test connectin from the workstation. This workstation is simulated with the Tiny Core Linux v.6.4.1 VM – 128 MB of RAM, 128 MB of vHDD and modern graphical environment with an e-mail client and Web browser.
The workstation has the correct private IP address. When we execute the traceroute command, we can see that there are five hops. With limit for the virtual ADSL link speed on only 4/1 Mbps, the masquerade on the both outgoing and ADSL router, we have real life results of the delays.
We must fill the IPSec configuration document in the beginning of the process. This document is in this scenario even more important. I will reveal the part of the secret here. We need to put the IP address on the outgoing interface for the IP address of the TFC router; in our example – 192.168.1.2.
Preparing Contoso router
We will prepare the Contoso router as usual. Oh, but… Here is one big but. We don’t have the IP address of the partner router. We knew that the FabrikaM router is with the address 203.0.113.29/30 and we easily prepared the peer settings.
The question is which address will be assigned to the ADSL CPE router? The answer is simple. The first free IP address from the pool assigned to the PPPoE service. In addition, it can change any time.
Oh, there can be even more fun. As you can see from the screenshot taken on the PPPoE access server, the ADSL router have the IP address 126.96.36.199/32. This address is public indeed, as the private IPs are from the 172.16.0.0. However, this IP can be private. Then we can have at least one more NAT device between our router and the Contoso router. Fun, fun, fun!
This bit longer introduction is here with a very good reason. We need to prepare the Contoso router’s Peer definition related to the TFC router. As we do not know its address, we will define the special generic peer definition. We will use the IP address of 0.0.0.0, which means any remote IP address.
There are three main differences between this scenario and the previous with public IPs. The first difference is that we do not know the IP address of the opposite side and therefore we can’t initiate IPSec communication.
The second difference is that this IPSec tunnel will pass through at least one NAT device. Therefore, we must enable the option NAT traversal. This option will switch the IPSec tunnel communication from the usual port 500U to 4500U.
Now, if the firewall blocking the UDP port 4500 (that means 4500U mentioned in previous paragraph) we can’t establish the IPSec connection. Therefore, check the firewall if you have problem with IPSec tunnel.
The third difference is that we need to build the IPSec policy on dynamic basis. This is related to the fact that we don’t know the SA source IP address of the remote peer and we can’t build the policy. This is the field SA Destination address.
I used the password Trange1. If more than one remote customer wants to connect to the router, they will all share this policy and its secret key.
All other settings are very common. We can choose more than one encryption protocol to enable connections from different devices. This is the second thing you should always to check. If the remote device is made for grandma’s home ADSL usage, then its capabilities can be very limited.
We should also extend supported authentication and encryption algorithms in the Default proposal. When we building dynamic IPSec tunnel, automatically generated policy will always use the default proposal settings.
We added the MD5 authentication and 3DES encryption protocols. In most cases, this will be enough.
This was very quick indeed. The Contoso router is ready to rock and to accept IPSec clients. We should prepare the other side.
On the TFC side, we need to prepare everything in the same way as we done before, like the router with the public IP address. We will begin with the IPSec peer definition. It’s very simple.
We know that the Contoso router is on the public IP address and we will use it. However, we need to enable the NAT traversal option. We know that there is at least one NAT device between this router and its peer.
All other parameters are already negotiated between the sides. In the scenario like this one, we must forcing remote side to comply with the main router. In real life scenario, we can have multiple remote devices and any alternation of the Peer definition can drop tunnels to all another routers.
The same applies to the Proposal part. We must harmonize it with the main router.
Now we coming to the most intriguing part here. We need to define the IPSec policy. The first tab is very common; our network and remote network.
The IPSec tunnel will be established between internal networks. However, the tricky part is coming.
Everything looks same as in the previous examples except the one field. The SA Source Address is the IP address on the outgoing interface of the router. This is not the public address on the ADSL router or ISP’s public IP. Keep this in mind. If something is wrong, check these settings.
All other parameters are the same and we will not spending more time on them.
The latest setting will be avoiding the NAT rules. We must define the rule that will allow this traffic to be excluded from the NAT process. We can do this on the tab IP > Firewall > NAT.
As you can see, we must position such rule on the top of the list of the NAT rules. The latest rule must be the masquerade NAT rule. Otherwise, we can’t access the resources outside our network.
Checking the tunnel
We can check that our router is connected with the remote peer in the Remote Peers tab.
Then we can try to connect from the client’s workstation to the server.
We can see in the router, on the Installed SAs tab, that the tunnel exchanging traffic.
The tunnel works. It’s time for the beer.
Command line scripts
For those who like to work from the command line, I prepared the scripts that can be used in your lab. You can download them here
I didn’t included the configuration of the MegaISP Access (PPPoE) server or the CPE router. You can build them very easy. Actually, it’s enough to put one VM before our router and to perform the NAT/masquerade on it.
If you would like to read more about other topics, like the PPPoE services, please, leave the comment. If you like my blog, I inviting you to start following it. You can also rate this post. Your feedback is welcome.
Stay tune for the upcoming articles and mighty tricks.