Balance 380 hub connected (among others) to a MAX Transit Duo.
SpeedFusion/pepVPN configured using IC2 (hub topology)
On the Transit:
2 x Verizon Cellular connections (priority 1 for the VPN)
1 x Satellite (priority 2)
Problem
Starting at midnight on Nov. 26, the VPN connection consumed 100-150 MB per hour just maintaining the connection (no activity to speak of from the Transit’s clients).
According to the DPI report on the Transit, 75% is DNS traffic, and none of it initiated by clients (the usage reports list about 25 MB of client traffic, the remaining 100-135 MB being unaccounted for).
When I disconnect the two cellular connections (going to the satellite only) the extraneous traffic drops to zero.
I have tried modifying the alive-check, to no avail.
When I drop the VPN the extraneous traffic drops to zero.
Since we cannot afford to spend 100-150 MB/hour for each cellular connection to keep the VPN up, this is a matter of some urgent concern.
Please see attached for a copy of the DPI report (the flat line in the middle is the satellite-only interval).
I have rebooted the B380 as well as the MAX Transit Duo.
Done [Ticket #779408]
Since the bandwidth consumption is so severe I expect I’ll have to turn off the VPN for now - I can turn it on for diagnostic purposes as needed.
Thanks to Yaw Theng and the tech support team at Peplink - they identified (and corrected) the configuration problem.
This level of service and support is extraordinary and much appreciated.
The problem was caused by the internal network configuration combined with a DNS attack on an externally visible IP address which mapped to the MAX Transit router across the SpeedFusion VPN:
This issue is solved now. It is due to a 1-to-1 NAT mapping at the balance 380 side.
There is a 1-to-1 NAT mapping setting at the balance 380 side. By configuring that in balance 380, it will forward all the TCP and UDP ports to 192.168.7.1. The IP address 192.168.7.1 is belonging to LAN interface of the MAX Transit. In that LAN interface, there is a DNS server to serve the LAN PC. Therefore, hackers from the internet can send DNS queries to your network and 192.168.7.1 will answer to those bogus DNS queries. Thus, eating up lot of bandwidth at the SFVPN
