Dear all,
I’m using RBM33G with 2 Huawei 909s-120 LTE module. I would to configure a failover internet connection on lte. Could you help me?
I tried this one https://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting but I didn’t help me because with LTE interface I don’t have a default gateway specified as ip address but only with name of the interface. In my case lte1 and lte2.
I tried also with static route and different distance but It run correctly only if the lte interface goes down. In many case the interface remain up but I don’t have internet connectivity and then the failover doesn’t run.
Have you some suggestion?
Thanks in advance.
Play with route distances. 1 for main LTE module and 2 for backup LTE module.
Regards.
To what I know you cannot do that without scripting. You can use various setups to force pinging of some reference IP addresses on the internet via lte1 and other reference IP addresses via lte2 so that you knew that not only the link is up but you can actually get somewhere, but for gateways other than IP addresses, it is not possible to translate this information into route availability without scripting.
The script might look like this.
Dear all,
I realized a little script to manage failover but on lte interface is more complicated.
I have a configure 2 routes and some firewall rule to allow ping to 8.8.8.8 only for LTE1 interface and 8.8.4.4 for LTE2 interface.
Then I have 2 default routes, one through LTE1 (with distance 1 because for me is primary link) and another one through LTE2 (with distance of 2).
With a script and the scheduler I check ping to 8.8.8.8 and 8.8.4.4 every 1 minute and if one of them fails I disable relative default route. For example if 8.8.8.8 ping fails I disable default route on LTE1 interface.
Where is the problem? I have to contact from remote my RBM33G and I’m not using SIM that allow bidirectional traffic on their APN. Then my routerboard can generate trafffic to INTERNET but it is not contactable from internet. In the past I used specific APN (more expensive for application machine 2 machine) but now I implemented a VPN with SSTP protocol.
When I switch from LTE1 to LTE2 the sstp client on my rotuerboard disconnect and immediatly create a new connection. Because I use RBM33G for transmit real data stream this disconnections can create some problem. Often disconnection of LTE1 interface can be very short and then the connection swith on LTE2 interface and after few seconds (when LTE1 become up) another one on LTE1. This create 2 sstp client disconnection. In case of using only one sim (in this case) I would have had only one disconnection 
.
Have you some idea?
Since years the problem of short outages of the primary path and the associated transient effects is solved by a “WTR timer” (Wait to Restore) which is used to delay the swicthover back to the primary path after it becomes OK. This is normally used to avoid falling back on false OKs, but could help a bit to you in terms that the total time of the outage would be shorter.
However, my approach would be to use one SSTP tunnel via each LTE interface and use a failover between these two tunnels for the critical data. It could then detect failures much faster than once in a minute.
Thanks a lot for your suggestion! A question: if I implement 2 sstp tunnel I have 2 different ip address client side. right?
Yes, you need to create two SSTP client interfaces, each will have another user and thus get another IP addresses. Only if each SSTP client would connect to a different SSTP server, there would be a danger that both interfaces would get the same IP address assigned.
Actually I have a service that acquire realtime data from remote RBM33G through a unique SSTP Tunnel. This service is connected to a remote ip address 192.168.254.10 (sstp interface).
I could implement second tunnel and assign to another sstp interface another ip, for example 192.168.254.9.
My service will continue to try to connect to 192.168.254.10 that is down. In this case I should implement also a procedure server side to swith to other ip address. Right?
Both tunnels will be internally on private addresses, so no NAT will interfere with routing operation. This permits you to create a bridge with no member ports on the remote device (the one with 2 LTE uplinks), assign a third IP address to that bridge, and on the SSTP server side, create two routes to that third address, each using another SSTP client interface address as a gateway.
Please check if I understood:
I create 2 sstp-client interface and sstp server asssign (for example) 192.168.254.9 at one and 192.168.254.10 at another one.
Then I create a bridge and add to the bridge both lte interface; I assign to the bridge an ip address for example 192.168.254.7.
On server side I create 2 route for 192.168.254.7 using sstp interface connected to 192.168.254.9 and interface connected to 192.168.254.10.
My service will contact always 192.168.254.7 that will be contactet trough sstp tunnel 1 or sstp tunnel 2 in function for example of a route distance. When an sstp tunnel go down the relative route will be disabled and the traffic go to other sstp tunnel.
Right? Sorry but in this case I could create also a simple bridge without any interface or a loopback interface. Right?
Your idea assumes creation of a WAN bridge on L2, but SSTP tunnels do not transport L2 frames, only L3 packets. So if you would like to take that way, you would have to set up EoIP tunnels inside the SSTP tunnels, i.e. the server would also have to be a Mikrotik device, and you’d waste a painful amount of packet space on tunnel headers. But yes, in such case, you could create a bond of the two EoIP tunnel interfaces on each end, or bridge them together with STP protocol enabled at the bridge.
My suggestion was an L3 one. I’m not sure how exactly SSTP tunnels work so maybe the two client addresses cannot be in the same subnet, but that’s not the key here, so let’s assume they can be 192.168.254.9 and 192.168.254.10 as you suggest.
The key is that the bridge at the client side would have no member ports at all (neither physical nor virtual), it will only be created in order to hold an IP address unrelated to any existing subnet, such as 10.22.33.44/32, and the routes at the server side will say (using Mikrotik syntax):
/ip route
add dst=address=10.22.33.44/32 distance=1 gateway=192.168.254.9
add dst=address=10.22.33.44/32 distance=2 gateway=192.168.254.10
At the client side, the routes will be
/ip route
add dst=address=the.data.collector.ip/32 distance=1 gateway=sstp-out1
add dst=address=the.data.collector.ip/32 distance=2 gateway=sstp-out2
There seems to be nothing to configure about tunnel state monitorinig on the /interface sstp-client, so either it is always on or it doesn’t exist at all. Depending on that, you may need to use a script to monitor both tunnels’ transparency at both ends and disable the route if the tunnel gets down.
Perfect I think to understand.
Then I should force sstp-out1 to use only lte1 and sstp-out2 to use only lte2. Right?
In which way? With policy based route?
This is the question I was afraid of 
One of problems associated to use of SSTP is that there is no way to configure anything but the remote address and port in Mikrotik’s SSTP client configuration, so you have nothing but the dst-address and dst-port as a base for policy-based routing (a simple one, using just mark=routing rules in chain=output and the routes with routing-marks and a distance=2 route with type=blackhole to prevent failover if the required WAN is down).
So on the server, you have to set port forwarding from some other port to the one on which it normally listens for incoming SSTP connections, so that it would effectively accept them on both.
If it is not possible, there is a way to achieve that effect on the client side, but it is a brain damaging one.
Then I can use another port on server side and redirect traffic to the standard 443 port of sstp-server. In this way I could force sstp-out1 on lte1 and sstp-out2 on lte2.
But the very important question is: suppose I configured all correctly; I have my service connected to 192.168.254.7; the traffic go from my service to sstp-server (that has 2 route for 192.168.254.7) and through the route with minor distance. If this route goes down, sstp server select the other route for 192.168.254.7 that use other lte interface on client side. In this case I have in any way an interruption of tcp traffic from my service to 192.168.254.7 or it is transparent?
There are two factors:
- there are no settings in the SSTP configuration related to keepalives, so I don’t know how quickly a failure of the SSTP tunnel will be detected and whether it will be detected at all before sending of a payload packet fails. So it may happen that the tunnel interface will be up long after the carrier path goes down, and only the first transport packet not to get acknowledged within timeout will cause the tunnel interface state change to down. If so, the TCP protocol in the payload will be heavily affected - google for “tcp meltdown”. That’s why I wrote before about “one of problems associated to SSTP”.
- RouterOS uses a routing cache which is on by default. I assume that if the gateway in use becomes unavailable, the cached route is replaced by a new one, but I’m not sure, so maybe you’ll have to disable routing cache.
If not for the above - yes, even if each of the packets of the same TCP connection would randomly choose one of the tunnels, as there is no NAT, the receiving side wouldn’t notice a difference, except that as the paths are very likely to have a different transport delay, the packets would be coming in shuffled order.
So all in all I’m afraid that the TCP session providing the SSTP transport will give up retransmitting and shut the tunnel interface down at about the same time when the payload TCP session will also give up retransmitting, so the route failover will come too late for the payload session to survive. But that’s a property of all VPN solutions relying on TCP transport. So if devices at both ends of the tunnels are under your control, you may prefer to use IPsec to create the tunnels, as it uses transport protocols without retransmission control and you can use e.g. pinging of the remote end to detect a breakdown of the tunnel much faster than in the SSTP case. This way, the payload TCP session would encounter some lost packets but wouldn’t break unless both paths would be down.
Dear sindy,
congratulations for your knowledge . Great!
I would to do a test also if I prefer a more simple configuration .
In any case I have sstp server on TCP port 443 and 444 (When I receive SYN on 444 I forward it to 444).
Then in client side I have sstp-out1 connected to 443 and sstp-out2 connected to 444. Now I’m trying to force sstp-out1 to use only lte1 and sstp-out2 to use only lte2. And I have some problem.
I configured a routing mark on mangle table.
In prerouting chain I have dst-address=public ip of sstp server, protocol=tcp and dst-port 443 and in this case the action is to mark-routing=to-443
A similar rule for the same dst-address, same protocol but dst-port=444 and in this case the action is to mark-routing=to-444
Then in routing table I added to rules for the same destination address (the sstp server public ip) but with different gateway interface (lte1 for one with routing-mark to-443 and lte2 for other one with routing mark to-444). Both sstp-out interface are connected but through the same lte interface. Where is the issue?
The issue is that mangle rules for packets originating from the Mikrotik itself have to be placed in chain=output.
Perfect. I add mangle rules in output chain and now I can see traffic counter on these rules but now only sstp-out1 can connect to server because it use default gateway. Then I disabled default gateway but there are the 2 specific rules to sstp-server public ip but they (sstp-out1 and sstp-out2) can’t connect.
Show me /ip route print detail and /ip firewall mangle print.
[admin@MikroTik] > ip firewall mangle print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=output action=mark-routing new-routing-mark=to-443 passthrough=no protocol=tcp dst-address=SSTP-SERVER-IP-PUBLIC dst-port=443 log=no log-prefix=“”
1 chain=output action=mark-routing new-routing-mark=to-444 passthrough=no protocol=tcp dst-address=SSTP-SERVER-IP-PUBLIC dst-port=444 log=no log-prefix=“”
[admin@MikroTik] > ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S dst-address=sstp-server-ip-public/32 gateway=lte1 gateway-status=lte1 reachable distance=1 scope=30 target-scope=10 routing-mark=to-443
1 A S dst-address=sstp-server-ip-public/32 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10 routing-mark=to-444
2 A S ;;; default-lte2
dst-address=0.0.0.0/0 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10
3 S ;;; default-lte1
dst-address=0.0.0.0/0 gateway=lte1 gateway-status=lte1 reachable distance=3 scope=30 target-scope=10
4 A S dst-address=8.8.4.4/32 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10
5 A S dst-address=8.8.8.8/32 gateway=lte1 gateway-status=lte1 reachable distance=1 scope=30 target-scope=10
6 ADC dst-address=10.92.119.88/30 pref-src=10.92.119.89 gateway=lte1 gateway-status=lte1 reachable distance=0 scope=10
7 ADC dst-address=10.122.174.196/30 pref-src=10.122.174.197 gateway=lte2 gateway-status=lte2 reachable distance=0 scope=10
8 ADC dst-address=192.168.0.0/24 pref-src=192.168.0.1 gateway=bridge1 gateway-status=bridge1 reachable distance=0 scope=10
9 ADC dst-address=192.168.254.1/32 pref-src=192.168.254.9 gateway=sstp-out2 gateway-status=sstp-out2 reachable distance=0 scope=10