Thanks a lot for your suggestion! A question: if I implement 2 sstp tunnel I have 2 different ip address client side. right?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?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.
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?
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.
This is the question I was afraid ofThen 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 ofThen I should force sstp-out1 to use only lte1 and sstp-out2 to use only lte2. Right?
In which way? With policy based route?
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.
There are two factors: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?
/interface bridge
add fast-forward=no name=bridge1
add fast-forward=no name=bridge2
/interface lte apn
add apn=mobile.vodafone.it name=lte1
add apn=mobile.vodafone.it name=lte2
/interface lte
set [ find ] apn-profiles=lte1 mac-address=02:1E:10:1F:00:00 name=lte1
set [ find ] apn-profiles=lte2 mac-address=02:1E:10:1F:00:00 name=lte2
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface sstp-client
add connect-to=sstp-server-public-ip disabled=no keepalive-timeout=10 name=sstp-out1 profile=default-encryption user=client1 verify-server-certificate=yes
add connect-to=sstp-server-public-ip:444 disabled=no keepalive-timeout=10 name=sstp-out2 profile=default-encryption user=client1bk verify-server-certificate=yes
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
/ip address
add address=192.168.0.1/24 interface=bridge1 network=192.168.0.0
add address=192.168.254.7 interface=bridge2 network=192.168.254.7
/ip firewall mangle
add action=mark-routing chain=output dst-address=sstp-server-public-ip dst-port=443 new-routing-mark=to-443 passthrough=no protocol=tcp
add action=mark-routing chain=output dst-address=sstp-server-public-ip dst-port=444 new-routing-mark=to-444 passthrough=no protocol=tcp
/ip route
add distance=1 gateway=lte1 routing-mark=to-443
add distance=2 routing-mark=to-443 type=unreachable
add distance=1 gateway=lte2 routing-mark=to-444
add distance=2 routing-mark=to-444 type=unreachable
add distance=1 gateway=lte1
add distance=1 gateway=lte2
/ip service
set www port=8080
/system clock
set time-zone-name=Europe/Rome
/system ntp client
set enabled=yes primary-ntp=193.204.114.232 secondary-ntp=93.204.114.233
/system routerboard settings
set silent-boot=no
[admin@MikroTik] > /ip firewall connection print detail
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0 C protocol=udp src-address=169.254.125.216:53141 dst-address=255.255.255.255:20561 reply-src-address=255.255.255.255:20561 reply-dst-address=169.254.125.216:53141 timeout=9s orig-packets=238 580 orig-bytes=14 629 788 orig-fasttrack-packets=0
orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=8.3kbps repl-rate=0bps
1 SAC protocol=tcp src-address=10.92.119.89:41381 dst-address=sstp-server-public-ip:443 reply-src-address=sstp-server-public-ip:443 reply-dst-address=10.92.119.89:41381 tcp-state=established timeout=23h59m59s orig-packets=3 851 orig-bytes=496 389
orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=8 969 repl-bytes=783 323 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=1224bps repl-rate=2.0kbps
2 C protocol=tcp src-address=10.92.119.89:58355 dst-address=sstp-server-public-ip:444 reply-src-address=sstp-server-public-ip:444 reply-dst-address=10.92.119.89:58355 tcp-state=syn-sent timeout=2s orig-packets=2 orig-bytes=120 orig-fasttrack-packets=0
orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps
[admin@MikroTik] >
This supports the idea in my post above, so add the masquerade rules and try again.
[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=0.0.0.0/0 gateway=lte1 gateway-status=lte1 reachable distance=1 scope=30 target-scope=10 routing-mark=to-443
1 SU dst-address=0.0.0.0/0 type=unreachable distance=2 routing-mark=to-443
2 A S dst-address=0.0.0.0/0 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10 routing-mark=to-444
3 SU dst-address=0.0.0.0/0 type=unreachable distance=2 routing-mark=to-444
4 A S dst-address=0.0.0.0/0 gateway=lte1 gateway-status=lte1 reachable distance=1 scope=30 target-scope=10
5 S dst-address=0.0.0.0/0 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10
6 ADC dst-address=10.8.28.60/30 pref-src=10.8.28.62 gateway=lte2 gateway-status=lte2 reachable distance=0 scope=10
7 ADC dst-address=10.64.118.204/30 pref-src=10.64.118.206 gateway=lte1 gateway-status=lte1 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.0/24 pref-src=192.168.254.7 gateway=bridge2 gateway-status=bridge2 reachable distance=0 scope=10
10 ADC dst-address=192.168.254.1/32 pref-src=192.168.254.10 gateway=sstp-out1,sstp-out2 gateway-status=sstp-out1 reachable,sstp-out2 reachable distance=0 scope=10
[admin@SSTP-SERVER] > 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=0.0.0.0/0 gateway=public-ip gateway-status=public-ip reachable via ether1 distance=1 scope=30 target-scope=10
1 A S dst-address=192.168.254.7/32 gateway=sstp-client1bk,sstp-client1 gateway-status=sstp-client1bk reachable,sstp-client1 reachable distance=1 scope=30 target-scope=10
2 ADC dst-address=192.168.254.9/32 pref-src=192.168.254.1 gateway=sstp-client1bk gateway-status=sstp-client1bk reachable distance=0 scope=10
3 ADC dst-address=192.168.254.10/32 pref-src=192.168.254.1 gateway=sstp-client1 gateway-status=sstp-client1 reachable distance=0 scope=10
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=0.0.0.0/0 gateway=lte1 gateway-status=lte1 reachable distance=1 scope=30 target-scope=10 routing-mark=to-443
1 SU dst-address=0.0.0.0/0 type=unreachable distance=2 routing-mark=to-443
2 A S dst-address=0.0.0.0/0 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10 routing-mark=to-444
3 SU dst-address=0.0.0.0/0 type=unreachable distance=2 routing-mark=to-444
4 A S dst-address=0.0.0.0/0 gateway=lte1 gateway-status=lte1 reachable distance=1 scope=30 target-scope=10
5 S dst-address=0.0.0.0/0 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10
6 ADC dst-address=10.68.177.64/29 pref-src=10.68.177.68 gateway=lte1 gateway-status=lte1 reachable distance=0 scope=10
7 ADC dst-address=10.119.181.56/30 pref-src=10.119.181.57 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.0/24 pref-src=192.168.254.7 gateway=bridge2 gateway-status=bridge2 reachable distance=0 scope=10
10 ADC dst-address=192.168.254.1/32 pref-src=192.168.254.10 gateway=sstp-out1 gateway-status=sstp-out1 reachable distance=0 scope=10
11 ADC dst-address=192.168.254.2/32 pref-src=192.168.254.9 gateway=sstp-out2 gateway-status=sstp-out2 reachable distance=0 scope=10
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=0.0.0.0/0 gateway=public-ip gateway-status=public-ip reachable via ether1 distance=1 scope=30 target-scope=10
1 A S dst-address=192.168.254.7/32 gateway=sstp-client1 gateway-status=sstp-client1 reachable distance=1 scope=30 target-scope=10
2 S dst-address=192.168.254.7/32 gateway=sstp-client1bk gateway-status=sstp-client1bk reachable distance=2 scope=30 target-scope=10
3 ADC dst-address=192.168.254.9/32 pref-src=192.168.254.2 gateway=sstp-client1bk gateway-status=sstp-client1bk reachable distance=0 scope=10
4 ADC dst-address=192.168.254.10/32 pref-src=192.168.254.1 gateway=sstp-client1 gateway-status=sstp-client1 reachable distance=0 scope=10
5 ADC dst-address=public-subnet/27 pref-src=public-ip gateway=ether1 gateway-status=ether1 reachable distance=0 scope=10
[admin@SSTP-SERVER] >
Redundancy always comes at a cost of complexity. So it is your decision what you prefer. I prefer simplicity of maintenance to simplicity of configuration.
And most important for your case, regardless what redundancy model you finally choose, I hope that the two Vodafone SIMs were used only for testing and for production you'll use SIMs from different operators not sharing network infrastructure (which, I admit, may not be an easy task in Italy in particular).
You can use all WAN at the same time to outgoing and/or incomming traffic.Could You be so please to explain how to make failover in case using RBM33G as out-of-band management access device:
- 2 x R11e-LTE as 2 Cellular Operator with physically separate infrastructur
- 2 x Eth - for WAN connectivity as 2 ISP with physically separate infrastructure
and last
- 1 Eth used for connection to Ethernet-accessible KVM (like Aten, StarTech) or to RS232 Port Server (like Digi, Lantronix) for out-of-band management.
Because out-of-band management used rarely and only something on a remote site goes wrong, basically, RBM33G must be remote accessible in any moment of time thru each of 4 connections:
each of 2 static IPs from ISPs, and
each of 2 dynamic IPs from Cellular Operators (DYNdns or other service used for IP, no matter).
I thinking the solution for this must be some script to periodically checking each of all of 4 WAN uplink connections (2 Eth + 2 LTE) and changing routing path inside RBM33G in case one (or many) of WANs not able to check certain IP (for example CloudFlare 1.1.1.1 or Google 8.8.8.8/8.8.4.4) within certain period of time (for example 10 sec).
Some sort of WAN uplink failover for 4 WANs.
Am I right?
Bandwidth-based load-balancing with failover. This presentation also covers Mangle.
This was presented at the MUM (MikroTik User Meeting) in New Orelans, USA.
Tomas Kirnak - YouTube: https://www.youtube.com/watch?v=67Dna_ffCvc
http://mum.mikrotik.com/presentations/US12/tomas.pdf
You can use DNS like [ isp1 | isp2 | isp3 | isp4 ].yourdomain.tld and isp.yourdomain.tld with 4x A record - know as RoundRobin.P.S. Several notes about tech support without head pain.
From technical support side would be best to have only one point of entry (vpnmgmt.example.com for example) on cloud provider, and delegate this cloud provider the periodically checking in cycle each of 4 IPs of device and notifying admins in case 1 or more of device's IP is unreachable for a certain period of time.
As I know CloudFlare doing this balancing from 2017, please read https://blog.cloudflare.com/introducing ... loudflare/ if You need to know more. And this is really not costly - starting from $5/month for 2 origins (https://support.cloudflare.com/hc/en-us ... -Balancing).
At end 2019 CloudFlare able to notify only on one email, but You may using this “alarm-notify” email to redirect to operator-depending SMS service or to Your support team Telegram channel.
I not ask, this is not related with MikroTik. This paragraph shoud have P.S. incarnation :).You may ask “why I need to pay extra for external monitoring instead to doing the same by my own servers?”
The answer are easy to understand: because this is more costly in $ and time (and also add some complexity and point of failure to your infrastructure), and You also need to place Your Monitoring servers (no matter physical or virtual) in different geolocations. CloudFlare, for example, ask only $15 for 8(!) different geolocations on different continents. More than sure, if Your client have small/middle business inside one country, 2 different points inside country + 1 point outside country is ok in most case.
You can use all WAN at the same time to outgoing and/or incomming traffic.
ETH ports you can assign into bridge/bonding with VLAN's for LAN & OOB/MGMT subnet. This one ETH1 can have VLANs to separate KVM/OOB etc.
ROS have got own DDNS (IP>Cloud who use main route table to do outgoing checking).
By CLI and scripting you can do any-way checking of WAN's.
At this moment please do lecture of this:Thank You so much!Bandwidth-based load-balancing with failover. This presentation also covers Mangle.
This was presented at the MUM (MikroTik User Meeting) in New Orelans, USA.
Tomas Kirnak - YouTube: https://www.youtube.com/watch?v=67Dna_ffCvc
http://mum.mikrotik.com/presentations/US12/tomas.pdf
Because I am a little bit frustrating after reading how Juniper describe High Availability and Redundancy:
https://www.juniper.net/documentation/s ... ce_all.pdf (From page 1651)
https://www.juniper.net/documentation/e ... bility.pdf
https://www.juniper.net/documentation/p ... bility.pdf
Even the Juniper conception are a little bit heavy to understanding, but from other side, - not linked to Juniper devices so hard.
How You comment the Redundancy described in "Concepts & Examples...." ? Sorry for dumb question, I am a newbe in MikroTik platform. Tnx!
You welcomeThank You so much!
Easy, in ROSv8 means MikroTik RouterOSv8 the all bug's and not exist features will be included. We can be sure that :)Because I am a little bit frustrating after reading how Juniper describe High Availability and Redundancy:
screenos6.3.0/630_ce_all.pdf (From page 1651)
high-availability.pdf
config-guide-high-availability.pdf
Even the Juniper conception are a little bit heavy to understanding, but from other side, - not linked to Juniper devices so hard.
How You comment the Redundancy described in "Concepts & Examples...." ? Sorry for dumb question, I am a newbe in MikroTik platform. Tnx!
[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=yes protocol=tcp dst-address=xxx.xxx.xxx.xxx dst-port=443 log=no log-prefix=""
1 chain=output action=mark-routing new-routing-mark=to-444 passthrough=yes protocol=tcp dst-address=xxx.xxx.xxx.xxx 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 SU dst-address=0.0.0.0/0 type=unreachable distance=1 routing-mark=to-443
1 A S dst-address=xxx.xxx.xxx.xxx/32 gateway=lte1 gateway-status=lte1 reachable distance=1 scope=30 target-scope=10 routing-mark=to-443
2 A SU dst-address=0.0.0.0/0 type=unreachable distance=1 routing-mark=to-444
3 A S dst-address=xxx.xxx.xxx.xxx/32 gateway=lte2 gateway-status=lte2 reachable distance=1 scope=30 target-scope=10 routing-mark=to-444
4 A S dst-address=0.0.0.0/0 gateway=lte2,lte1 gateway-status=lte2 reachable,lte1 reachable distance=1 scope=30 target-scope=10
5 ADC dst-address=yyy.yyy.yyy.yyy/24 pref-src=zzz.zzz.zzz.zzz gateway=lte1 gateway-status=lte1 reachable distance=0 scope=10
6 ADC dst-address=10.167.111.100/30 pref-src=10.167.111.101 gateway=lte2 gateway-status=lte2 reachable distance=0 scope=10
7 A SU dst-address=172.18.0.0/24 type=unreachable distance=1
8 ADC dst-address=172.18.0.1/32 pref-src=172.18.0.203 gateway=sstp-out1 gateway-status=sstp-out1 reachable distance=0 scope=10
9 ADC dst-address=172.18.0.254/32 pref-src=172.18.0.204 gateway=sstp-out2 gateway-status=sstp-out2 reachable distance=0 scope=10
10 ADC dst-address=192.168.0.0/24 pref-src=192.168.0.1 gateway=bridge1 gateway-status=bridge1 reachable distance=0 scope=10
Dear sindy,As the first step I would check, using /tool sniffer quick, that the ping requests and responses really take the routes you expect them to take when both LTEs and their associated SSTP tunnels are up. It may be that there is some hole in your policy routing and the requests or the responses actually take a different route than you expect, so when the LTE goes down, it takes the SSTP some time to notice that and put down its virtual interface so that the other route could come into use.
So while both LTEs and SSTPs are up, run /tool sniffer quick ip-address=172.18.0.203 protocol=icmp and see the interface names in the packet list; then change ip-address to 172.18.0.204 and look again.
[admin@MikroTik] /tool> /tool sniffer quick ip-protocol=icmp ip-address=172.18.0.203
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
sstp-out1 16.078 33 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 16.078 34 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 17.084 35 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 17.084 36 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 18.08 37 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 18.08 38 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 19.08 39 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 19.08 40 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 20.08 41 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 20.08 42 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 21.08 43 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 21.08 44 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 22.078 45 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 22.078 46 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 23.078 47 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 23.078 48 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 24.084 49 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 24.084 50 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
sstp-out1 25.078 51 <- 172.18.0.1 172.18.0.203 ip:icmp 56 0 no
sstp-out1 25.078 52 -> 172.18.0.203 172.18.0.1 ip:icmp 56 0 no
[admin@MikroTik] /tool> /tool sniffer quick ip-protocol=icmp ip-address=172.18.0.204
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU FP
sstp-out2 0.92 1 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 0.92 2 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 1.92 3 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 1.92 4 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 2.92 5 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 2.92 6 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 3.904 7 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 3.904 8 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 5 9 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 5 10 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 5.959 11 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 5.96 12 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 6.92 13 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 6.92 14 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 7.911 15 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 7.912 16 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 9.16 17 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 9.16 18 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
sstp-out2 10.12 19 <- 172.18.0.254 172.18.0.204 ip:icmp 56 0 no
sstp-out2 10.12 20 -> 172.18.0.204 172.18.0.254 ip:icmp 56 0 no
Dear sindy,In this case, and supposing the outer policy routing (of the SSTP transport packets) is correct as well, the only thing left which comes to my mind is that the processing of the shutdown of the LTE takes so much CPU that the handling of the pings is affected.
How many pings are lost on the tunnel which stays up? If more than two (assuming you send them in one second intervals), you might be able to spot a spike in CPU load if you run /tool profile (while connected to the Tik using its LAN interface) and disable one of the LTEs. But it sounds weird to me, given that the CPU is not among the weakest ones used.
Also, if you run the tool sniffer pointing to the internal IP of the tunnel which remains up, you may see whether the ping requests and/or responses are really lost or just delayed (if a response is delayed past the expectation window, the recipient ignores it). Plus I would do the same also at server side.
Sorry it is strange: now I have problem also with continous ping.What exactly means "continuous ping"? Something like interval=50ms? If you don't run this "continuous ping" while shutting down the LTE, how do you check the transparency of the second tunnel?
12:02:36 interface,info lte1 link down
12:02:36 system,info device changed by admin
12:02:36 dhcp,info dhcp-client on lte1 lost IP address xxx.xxx.xxx.xxx - lease stopped locally
12:03:00 sstp,ppp,info sstp-out1: terminating... - connection timeout
12:03:00 sstp,ppp,info sstp-out1: disconnected
12:03:00 sstp,ppp,info sstp-out1: initializing...
12:03:00 sstp,ppp,info sstp-out1: connecting...
12:03:13 sstp,ppp,info sstp-out2: terminating... - connection timeout
12:03:13 sstp,ppp,info sstp-out2: disconnected
Sure. Each tcp session use different lte interface.So are you really sure that the transport connections (TCP sessions to ports 443 and 444 of the SSTP server) do use the paths you expect them to use? Use the tool sniffer again while both LTEs are up and check that packets to/from SSTP server's IP address and port 443 use LTE1 and packets to/from SSTP server's IP address and port 444 use LTE2.
OK. Before I start more speculations, try to replace the two type=unreachable routes with routing-mark=to-44x by type=blackhole ones, change their distance to 2, and try again.Sure. Each tcp session use different lte interface.So are you really sure that the transport connections (TCP sessions to ports 443 and 444 of the SSTP server) do use the paths you expect them to use?
I tried but It's the same ... I think there is something that drop tcp session 443 or 444 when I shutdown an interface lte...OK. Before I start more speculations, try to replace the two type=unreachable routes with routing-mark=to-44x by type=blackhole ones, change their distance to 2, and try again.Sure. Each tcp session use different lte interface.So are you really sure that the transport connections (TCP sessions to ports 443 and 444 of the SSTP server) do use the paths you expect them to use?
ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 X chain=srcnat action=masquerade log=no log-prefix=""