So far, we have discussed how to connect the two sites through an IPSec tunnel. Most readers will be satisfied with that, as these scenarios cover most real-life situations. However, we may have a need to interconnect three or more sites using the IPSec tunnels,
Although rare, these scenarios are possible. However, we need to plan everything carefully, as we will need more IPSec policies between routers. Therefore, I will describe here how to connect the “road warrior” users with distant site.
I have used similar settings a few times. Now, most customers have only two locations. And, while I considering this scenario and is it’s interesting to you my audience, I received an e-mail from one of my readers with the question how to complete this setup. As I helped him to make things work, I decided to share this information with you all.
Before we begin, I must write “the word of caution” – cue dramatic music! I will show you how to setup the Mikrotik routers. Other routers may or may not work in the same way. If those routers have any problem with multiple IPSec policies between the same peers, then this is a problem in their software and you can’t do much. In which case, you can try to upgrade the software on your device or simply replace it with the Mikrotik device.
Anatomy of this scenario
When we explore this scenario, we can see that in essence we have two basic scenarios in its essence. We already discussed how to connect two sites using IPSec tunnel. We then discussed how to connect “road warriors” to our company site.
Our new scenario will assemble both scenarios in one system. Here is a graphical representation of our scenario.
As always, I’m using my virtual lab to simulate the real-life scenario. For your convenience, I’ve only highlighted only the important part of the lab.
We have two sites – Contoso and FabrikaM. The FabrikaM server sends the e-mails to the Contoso e-mail server. Then the e-mail server distribute these e-mails to the end users.
In addition, we have either the employees or contractors that will use the VPN connections to access the Contoso network. These users are somewhere outside the Contoso network.
Everything is easy if all resources are in the Contoso network. However, let us assume that the FabrikaM server is another resource that should be accessed by remote users. Obviously, we can configure the VPN server on the FabrikaM router and allow the road warriors to access this site too.
The downside of a such scenario is that we need to configure and administer two routers on two sites. In addition, every user must have two VPN connections on his device. Moreover, they can connect only to one of the sites at a time.
Therefore, they need to connect to the first site, finish the work, then disconnect from it and connect to the second site. As you can see, if the user needs to work again on the first site, he should again disconnect from the second site and reconnect on the first site.
To make a long story short – uncomfortable. We should make this easier for us as administrators and at the same time for our users.
Dude, where is my server?
In the beginning, we have the site-to-site IPSec tunnel between the Contoso and FabrikaM sites. We need to be sure that this tunnel works fine. In our case, that means that, for instance, the FabrikaM server can send the e-mail to the Contoso server.
The second part is the L2TP/IPSec VPN tunnel between distant users and the Contoso router. Our remote users should be able to connect to our router. When they establish the VPN connection, they should be able to access the Web or e-mail servers.
We can see on this screenshot from the Contoso router that we have two IPSec connections. The site-to-site connection is highlighted in yellow, while the L2TP/IPSec connection is the other pair.
In addition, the remote user must have the default gateway (and consequently the default route) set through the Contoso router. That means that all traffic will be sent through the VPN connection to the Contoso router. This router will make the decision what to do further.
As this is the PPP connection, the local interface address is simultaneously the gateway for that connection. This is the reason why we can see that the gateway IP is the same as the interface address.
Please, keep in mind that the IPSec part of the road warrior scenario is just encryption and the data protection. The main connection is the L2TP tunnel. As the L2TP tunnel can have the IP address and participate in the routing process, we have two local segments from the perspective of our router.
Don’t be confused by the IPSec part here. You can forget about it when we’re talking about the L2TP clients. Therefore, our router can see the LAN segment and the PPP segment. Both segments are directly connected to the router. Moreover, the router will forward the network traffic between them without any special rule.
Let us try to access the server from our remote client.
As you can see, both the ping and traceroute commands failed. We can’t access the server.
What do we need?
We can’t access the server because the Contoso server can’t route the traffic from the remote client to the FabrikaM server. This is the root cause of this problem and I will show you why.
As the first step, we will look at the IPSec policies on the Contoso router.
As we expected, there is only our policy for communication between the LAN segments and the dynamic policy for the PPP client. On the FabrikaM side it’s similar – only the policy of LAN communication.
Obviously, we need the new policy for the IPSec tunnel. That policy should cover the IP address range for the PPP clients. We can see that range in the IP Pool menu.
Adding the policy
We know what we should do. We need the new policy for this PPP range on both routers. As we using the same routers, we already knew the SA source and destination addresses. We don’t need the new peers.
Here is the policy on the Contoso side. I highlighted only the important part about the IP addresses here. The rest of the settings are the same as in the other policy.
The policy on the FabrikaM side is similar. We just need to reverse the IP addresses.
Testing the tunnel
We can test the tunnel. I will send the ping packet to the FabrikaM server.
The first ping packet timed out, as the IPSec tunnel needs some time to establish. The key exchange process is really fast and we will lose only one or two pings.
As our FabrikaM server is actually the Mikrotik router, it has the Web server. We can open it’s Web admin console (Webfig) in the browser. It’s the same as opening any other Web page – we proved that this works.
This works! We successfully configured the IPSec tunnel for the road warriors.
The next steps
Now is your turn. You can download the command line script here. This file contains all the commands to setup the whole scenario from scratch.
If you missed any of the previous parts of my IPSec series, you can check the first part with the IPSec theory and then navigate from it to the post about other common scenarios.
You can try to connect the fourth location in this scenario. Then you will need to make the appropriate policies to route the traffic between these sites.
However, I do not recommend making too many IPSec tunnels. It will be much easier and error free if you use the tunnels that can route the traffic. In case you’re using the tunnels without encryption, like L2TP or IP-IP, you can use IPSec to protect them.