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?...
- 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)
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.- SSTP, OpenVPN(TCP)
Works, is fine, but TCP over TCP should not be the way to go for Site-to-Site-VPNs.
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.4 Tunnels would be possible.I will give it a try. Just to be sure:
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?
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.- 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, 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"?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...
It is certainly possible without 4 tunnels in so called road warrior setups. Set up ipsec+modeconf and problem solved, there are even example sin the manual:Why isn't it possible to configure an IPSEC-tunnel dynamically where the HQ does not know the IP of of the BO (dialup)
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?@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).
...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.L2TP works fine over provider NAT (e.g. 4G).
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".how do you handle the problem, that all the L2TP-tunnel will share one PSK?
I don't consider that a problem. The L2TP tunnel additionally has username and password, and we set that different for each branch office.how do you handle the problem, that all the L2TP-tunnel will share one PSK?
Yes, and no.Hi!
But with L2TP and IPSEC, I would have to use the same PSK for all the peers, right?
Using only one tunnel at a time actively is absolutely ok for me. Balancing is not important - only failover...
Can you provide links to these hints? That does not make sense to me.I found several hints in the forum, that xauth should not be used with site-to-site-VPNs.
Well, I cannot speak for Tomáš but I suppose he had in mind that you should not need to use xauth for site2site setups, as it adds complexity without any added value if you have static addresses at both ends and no redundancy requirements. But as soon as you have a dynamically changing address at the BO end, it becomes a road warrior case as you cannot tell this remote peer from another one by its IP address at the HQ end, so you need to use some other means. DynDNS update from BO and use of the DNS name as remote in HQ configuration is one possibility, but with your "full mesh" where you need two distinct local peers at BO to share the same remote of HQ I'm not sure whether the DynDNS update can be done without scripting in such a way that you would have a distinct DNS name for each of the two WAN addresses. And even if this worked, two BOs could hit the same public IP from the mobile operator's NAT pool if the operator assigns private addresses to the LTE clients...at 04:00 min on the slideshare
The xauth? Just change the setting.Hi!
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.