Speedfusion Application DPI Overhead

We are looking to install an Iridium / Inmarsat satellite link to the WAN port of our Transit Cat 18 for ocean passages. The link is slow at 100 kbps and expensive at $10/MB.

I would like to only allow whatsapp traffic through this link. The only way to filter and enforce outbound WAN by application is to send the traffic through Speedfusion Cloud (which we subscribe to). I understand that a few packets of data gets transmitted to Speedfusion servers before filtering takes place. Can anybody quantify how much data this is before unintended traffic is dropped?

Another way would be to enforce by protocol/port and destination IP. However, I understand Whatsapp uses quite standard ports and the IPs are always changing. Has anybody managed to workout a ruleset that only allows Whatsapp data?

Thanks in advance

Nez

I don’t have an answer for you on the dpi, but I would try to narrow down the traffic another way.

Can you do this by using an outbound policy for domain name rule instead?

Another option would be to allow only the ports specified in this article?
https://community.broadcom.com/symantecenterprise/communities/community-home/digestviewer/viewthread?MessageKey=ab15be94-1f47-4de1-8dba-8ddcb1f2c30b&CommunityKey=3ccfc309-780b-4c9e-9224-f2a425f538f5&tab=digestviewer#:~:text=Dear%20Amit%2C-,Whatsapp%20uses%20TCP%20443%20(HTTPS)%20to%20pass%20the%20majority%20of,need%20to%20allow%20on%20Firewall%20.

You could try using the content blocking feature on the TST to deny most other types of traffic but as you already point out:

So how effective this is will ultiamtely depend on how up to date the Peplink DPI definitions are - for a reference we use a lot of Fortinet firewalls and they update multiple times a day (and at $10/Mb even those small updates would end up costing a small fortune over a month!) and they are also doing what I consider “real” DPI where we are effectively MITM all the end users traffic not just doing passive inspection of it.

A simpler strategy may be to just block anything going out except traffic sourced from a couple of specific devices, and perhaps consider getting a specific device to be used for messaging that has very little else installed on it, grab a cheap Android phone and install nothing but WhatsApp on it and disable every feature you can find that would possibly use data.

Further to the above, is it possible to apply the firewall content blocking (application blocking) by WAN type. I am thinking that if this is possible, I can block everything except for IM services.

If this is not possible, how does the firewall recognise Whatsapp traffic (there is a specific application selection for it in the firewall options) and can I replicate that process as an outbound rule?

I’m not 100% sure this will do what you want but in outbound policy if you set the destination to your SF Cloud you should then be able to select application types.

You could then make an outbound policy with an enforced priority for the WAN and just don’t include the satellite link in the list, and tick the “drop traffic” option for when that WAN is not available.

I’m also not sure, but I believe this would only work if packets are actually passing down the vpn tunnel to check the type of traffic before applying the rule.

I’m not sure that would be the case though, if the TST is not doing the inspection why have the rules as at that point you are just sending all your traffic to the destination matched in the rule.

The TST must be doing some inspection or classification as how else would it know whether to pass the traffic or drop it or process it according to some lower priority rule?

Testing and verifing the operation is probably the best way to be sure, other than that you are limited to the content blocker as I do not believe it is possible to use the DPI signatures in firewall rules at the moment. The DPI functionailty I believe is a relatively recent addition to the Peplinks, so hopefully over time they will expand its capabilities and how granular it can be in matching traffic.