I really love using mikrotik devices for most of the networking jobs in my projects, but there is one thing, that avoided using mikrotik many, many times:
It is SO hard to use VPNs with dynamic IPs or MultiWAN!
One example:
Branch offices have: DSL-internet + LTE backup (dynamic and provider-NAT)
Headquater uses: 2x internet, static IPs, different providers
The goal is to have a working VPN-solution if ANY of the internet-lines fails, or if one line on each site fails. If the main-interface on the branch-office fails, the VPN must connect over the other line.
Pure IPSEC
Mikrotik does not (like other vendors) accept pure Aggressive mode with dynamic IPs. The only option would be to configure 4! tunnels with nasty scripts that configure dyndns on both branch-office-internet-lines.
Why isn’t it possible to configure an IPSEC-tunnel dynamically where the HQ does not know the IP of of the BO (dialup)
IPSEC+L2TP
Works, but I can only use one IPSEC-PSK for ALL the tunnels on the HQ, if I want to use dynamic SAs. That is a crazy limitation.
EoIP
Great protocol, but one more time: Sucks with dynamic IPs (and MultiWAN mostly lead to dynamic IPs).
SSTP, OpenVPN(TCP)
Works, is fine, but TCP over TCP should not be the way to go for Site-to-Site-VPNs.
So the question:
Did I miss any nice option to do this without crazy complicated setups that combine technologies and shrink the MTU more and more (like EoIP over L2TP)?
I think we’ve already discussed it elsewhere. If you have static IPs on the HQ side, you can configure plain IPsec from the BO with changing addresses or even running on private addresses behind a NAT, and use GRE tunnels over the IPsec connections. So you’d have four IPsec “sessions” between the four WAN interfaces:
BO1<->HQ1
BO1<->HQ2
BO2<->HQ2
BO2<->HQ1
At each end, you would use the usual script-less multi-wan arrangement over these 4 VPN tunnels. A GRE tunnel is represented by a virtual interface so you use normal routing tables with check-gateway and distance to monitor the availability of the tunnels and set up priority of their use. Or you can use OSPF to control the redundancy.
Not sure if I am not understanding the question, but will answer with a question, how will you make a telephone call to someone if you don’t have his/her tel number, or go and visit someone if you don’t have his / her address?
SSTP, OpenVPN(TCP)
Works, is fine, but TCP over TCP should not be the way to go for Site-to-Site-VPNs.
Running on several sites, primary at 2mbps and sites at 512kbps they only share internal routes, Domain controller replication runs without a problem and hits 460kbps for each site instant messaging XMPP also works without problems and they have no extra latency inside the tunnel. so i think this works just fine.
@sindy:
Yes, I saw this answer. 4 Tunnels would be possible.I will give it a try. Just to be sure:
HQ:
Define two IPSec Peers.
Peer 1: Local IP is WANHQ1-IP
Peer 2: Local IP is WANHQ2-IP
Remote-IP is always 0.0.0.0
→ But how are the SAs set, if I do not know the remote-IP?
branch-office
Define 4 IPSEC-Peers
Peer 1+3: Remote IP is WAN-HQ1
Peer 2+4: Remote IP is WAN-HQ2
Local IP must be set through IP-Cloud-Feature in case of LTE?
Sorry, but its hard to understand for my, why the local-IP of the branch-office does play any role. My current-setup from another vendor is a lot less powerful than mikrotik, but I can define an IPSEC-peer that can only be run from one site without knowing its address…
@CZFan:
Thats why I wrote “dialup”. The BO-User will do the call and so: “The called party does not need to know the number of the caller to answer the call”.
You don’t know the remote IP in advance, which means you cannot use the IPsec session which is created automatically if you fill the IPsec Secret field in the /interface gre configuration. You have to use xauth mode of the peer, allowing you to tell the remote peers from one another (as you’ll have two remote peers per each BO for each local peer) by username, and you can either configure policies at BO peers and let the HQ peers mirror them (using generate-policy=yes at HQ side) or you may use mode-config to configure the BO peers from the HQ side.
You’ll have to use tunnel mode of IPsec and use private addresses as endpoints for the GRE tunnels, as with transport mode of IPsec, you would have to use scripts to adjust the GRE configuration as the remote addresses would change which is what you don’t want to do.
The two peers towards the same HQ address will have to use different local addresses. One possibility is to use fixed private addresses, firewall rules or routing rules to make sure that each of these source addresses uses a different WAN to establish a connection to the same remote destination, but I am not sure this can be achieved without scripting as the interface cannot always be used as a gateway. And if you have to use scripting, you may update the peers’ local addresses straight away instead of modifying the routing tables.
Sorry, you’ll have to use other words or other language to express this. How do you identify that “one site” if you don’t know its address so that you could accept the “call” from that peer only if it comes from that “site”?
@sindy:
I think, the biggest problem is, the aggressive-mode is not fully supported. There seems to be no possiblity to check the peer-id (i did not find one). Thats why I cannot seperate the traffic).
@mrz:
I will give it a try. is mode-config only possible with an IP-pool, or are static IPs supported, too?
I must be missing something. Why you need to check the peer-id, why is username not sufficient for you (I even assume it is actually the same thing) to distinguish the peers from one another?
For a configuration like that I configured the usual 2-provider setup (with static IP) at the main office and also L2TP server on 2 external IPs,
and for branch offices I use L2TP where the main office is accessed using a domain name (a hostname under our main domain, registered in DNS on internet)
where the single name has the two addresses of the main office. Normally the branch offices will get a random connection over one of the
two lines (DNS rotation) but when one line fails they will re-try until they get the address of the working line and connect to that.
Setup BGP to route the main- and branch office subnets and it all works automatically. L2TP works fine over provider NAT (e.g. 4G).
For the branches that have static external IP I use a static GRE/IPsec tunnel instead. Plus a GRE6/IPsec tunnel for good measure.
(it has happened that IPv4 connectivity was down while IPv6 was still working)
…unless two BOs hit the same public IP on the provider NAT, causing an unexplainable headache as it will happen only once in a blue moon. There is a remedy but I wouldn’t call it simple.
Fortunately in our case due to the 2 external IPs (which I did not completely describe, in fact we use 4 external IPs from 2 /29 subnets to have simultaneous GRE/IPsec and L2TP/IPsec) it “never” occurs.
It could be different when you have many connected branch offices.
Ah, I forgot your other topics was dealing with this one… in that case, you would have to use certificates to replace the PSK. Like with GRE, you would have to configure IPsec manually instead of just telling the L2TP “use IPsec with this PSK”.
I think you should not use EoIP tunnels. redesign your network so it can be routed.
in my experience it is unwise to have multiple tunnels in a balanced (i.e. ECMP) setup when there are Windows systems on the network.
As the bandwith of the tunnel from branch office to head office is likely determined entirely by the branch office main internet connection,
and you usually do not want to throw a 4G connection in the mix for other purposes than backup (due to data bundle limits), it is best to
have only a single active tunnel from each single IP address. So, 1 active L2TP from each branch office DSL to one of the two head
office connections, chosen randomly to balance their use (e.g. as I wrote before using DNS).
When both tunnels are up at the same time, make sure only one is really used in each direction, e.g. using BGP routing. It is not a problem
when the routing is asymmetric, but when you have balancing like ECMP you will create packet reordering and it will severly affect
throughput on Windows systems due to sub-optimal TCP implementation (on Linux it isn’t much of a problem).
Yes, if You want to go the easy way: interfaces → ppp → L2TP client, and mark “use IPSec”.
No, if You can do it the hard one: set it up by hand, through the IPsec config, and use xauth. True, the secret would be the same - but not the IPsec user and password. Set up an L2TP connection without marking “use IPsec”. Set the firewall to only allow L2TP outbound connections that are IPsec encrypted. And now, the cherry on top: If your server has dynamic IP, You will need to run a script, in order to keep the IPsec configuration with the right server IP.
Took me some time, with help from others here, to crack this. But it works: I have 3 dynamic IP clients connecting to one dynamic IP server.
I found several hints in the forum, that xauth should not be used with site-to-site-VPNs. The examples are always just for RoadWarriors.
How did you handle this? I do not want to use dynamic IPs for the “client-branch-offices” inside the L2TP.