A SpeedFusion connection from a site (HD2 67) to a SpeedFusion Cloud server (the SJC farm)
The connection expected to bond three HD2 WAN interfaces:
Cellular 1 and Cellular 2 and WAN
The WAN connection is to a BR1 or a Transit Duo, which then employs a cellular connection to the net
All units are on FW 8.1.2
The (my) expected behavior is that all three WANs should be employed in setting up the SF tunnel:
We have employed similar two-layer SpeedFusion connections in other locations, albeit in failover (not bonding) versions.
The same architecture but with an in-house SpeedFusion connection (a Balance 380) instead of SFC, established using InControl2, suffers the same problem.
Setting the WAN priority to 1 and the cellulars to 2 in IC2 suffers the same problem.
Setting the WAN to the only interface (disabling the cellulars in IC2) suffers results in no connection being established at all.
Setting up a separate SpeedFusion connection from the Transit to the B380 (with no connection from the HD2) is successful, thus there seems to be no issue with the Transit (or BR1) as such.
I am probably missing (or messing up) something trivial, but it has me stumped.
That would get in the way of other uses of the transit. Be that as it may, it did not work (1-1 set up, no connection).
You betcha. With the HD2 doing simple load-balancing the transit handles the bulk of the traffic (it is a CAT 12 with Verizon and T-Mobile SIM-cards, it is wonderful (different topic, that)).
One peculiarity (as in unusual) element comes to mind: The two cellular connections from the HD2 are static IP addresses. I don’t know why that should matter, but it is uncommon.
Did that. No go.
Tried TCP (instead of UDP). No go.
Tried multiple tunnels (one being WAN only). No go.
Tried disabling the Verizon modem (leaving T-mobile) on the transit. No go.
And I tried SFC - it just works. Except it does not (fully).
From the hd2 , which device are you trying to connect to?
Is the hd2 is initiating the connection?
The hd2 has the IP address to connect to and the other side is blank,right?
Simple ideas:
use IP instead of fqdn.
disable wan health check on.
Reboot
Change firmware version , try lower and higher (even beta)
SFC (for simplicity of the test) and a B380 HW6 (for real)
The configuration is employing IC2 - the B380 is a hub and being controlled by IC2 it does not allow manual SF profiles
N/A for an IC2 configuration. Besides, a quick check of the purported setup indicates that the B380 IP address is correctly employed.
Rebooted √
WAN health check - not about to do that (besides, the connections are all very healthy)
Firmware? Nope, we are not going to roll anything back - that is not a viable option.
@zegor_mjol, please help to isolate the problem. You may swap the SIM cards between Transit/BR1 and cellular 2 of HD2. If the problem follows the SIM card, I believe the ISP blocked the data port (UDP 4500 by default). If the problem sticks with WAN of HD2, I believe something not right in the Transit/BR1.
The Transit is up on a pole and rather inaccessible, so a swap would be a last resort.
As a substitute for swapping:
The Transit has three SIM cards - one Verizon, one T-Mobile and one Visible (a Verizon MVNO). The connection test has been run with each of these being the sole cellular connection (ordinarily Verizon + T-Mobile would be the active SIM cards). They all failed, so it seems not to be a case of carrier-specific port blocking.
The Verizon SIM card in the Transit is on the same account and plan as the Verizon SIM cards in the HD2. The HD2 cellular connections support SpeedFusion connections.
If there were a port blocking issue then I would expect that a SpeedFusion connection with the Transit as an endpoint would fail as well. That is not the case - we have succeeded in connecting the Transit directly to the B380.
Changing the port of the HD2<->B380 connection (from 4500 to 5500) did not make a difference.
I have also factory-reset the Transit, to no avail.
Once you get this odd I would break out the network sniffers.
So your key questions are… #1 are the session start packets leaving the WAN link? #2 are the session start packets leaving the Transit on its Cell link. #3 Do the packets reach the far end (B380) and how are they formed/NAT etc.
#1 and #2 can probably be analyzed from the support.cgi on the Transit.
#3 is best analyzed either by network span, if your switches support that, or via the support.cgi on the B380.
Once we know if the packets actually reach system #3, we can then analyze who is dropping or mangling the data.
@Paul_Mossip is correct. Doing Network Capture from Transit will help to identify where the SpeedFusion data packet (UDP 4500) of HD2 is dropped.
@zegor_mjol, may I know there is an existing SpeedFusion tunnel between Transit and Balance 380 and you wish to establish another SpeedFusion tunnel between HD2 and SFC at the same time?
A bit beyond my current tool/skill set, unfortunately,
There is none - the Transit is not the end-point of any SpeedFusion connection (except once, to see if there were any issues setting up a Transit ↔ B380 connection, and once that was established the connection was dismantled again).
At this time the primary goal is to establish a SpeedFusion connection between the HD2 and the B380, a connection that employs all three WAN interfaces of the HD2 (WAN, cellular 1, cellular 2) and where the WAN connection goes to the Transit which then should be a simple conduit to the internet. (The transit does other things as well, but nothing employing SpeedFusion).
There is no attempt to have the Transit as a SpeedFusion connection end-point for any connections.
The HD2<->SFC connection is simply a minimalist test rig, to see if the same problem (lack of connection across the WAN to the Transit and out) manifested for that architecture as well. Which it did.
I can dismantle that (and will do so now) since we have established that the HD2<->Transit<->B380 connection problem manifests for both SFC and B380 connectivity.
@zegor_mjol, I just tried your setup just now, and have no issues getting either device to connect to a 580. I did set this all up manually, so its technically P2P, not a hub scenario. Also I have manually set the ports to sequential numbers (ie: HD2:4707, Transit:4708, and because its a SF device behind a SF device the handshake port is different 33015).
For testing - first try I just did a HD2 tunnel, second time was a Transit tunnel and HD2 tunnel, third was both tunnels, and fourth was disabling cellular on HD2 leaving only WAN1 up. Every time there was no issue with the tunnel dropping.
Try switching to a P2P/Star setup over a Hub setup, you can click the advanced options and add an extra device. This might help, I didn’t test this, as all my SF’s are manual and programming through IC2 overwrites the current setup.
Thanks for trying it out. It really is puzzling, and the base case (a simple SpeedFusion Cloud architecture) failing has me stumped.
There may be work-arounds (the simplest being to just ignore the fact that the WAN connection just does not fly), but getting at the root cause would be good. I hope @TK_Liew figures it out
