Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Any experience with an excessive number of ThunderVPN hits?

I recently set up a new XG firewall at our main branch location in order to assist with IPS and application control service.   I am currently using the "Block high risk (Risk Level 4 and 5) apps" setting for app control.

What I am noticing is a large amount of ThunderVPN hits on our network, and I'm at a bit of a loss on what could be causing this traffic.  I'm glad they are being blocked, but I wanted to see if anyone had any experience with this and what might be utilizing this service.

Our entire network consists of Dell workstations and the traffic is coming from various IP addresses, not just one machine.

Thanks in advance for any information!



This thread was automatically locked due to age.
  • LuCar Toni - I sent you a PM on 10/6 with a pcap attached as well as a conntrak that captures this traffic.  Did you not get my PM?

  • I forwarded this pcap to Labs. But they have to analyze the traffic and find the root cause. More pcaps submitted by the process above would be helpful to find the pattern. 

  • I see, ok.  I submitted last night the same pcap and conntrak files at the file submission link you shared above.  It created a case (04501211).  Over night it was looked at and closed.  The comments for each file were "not detect-worthy" ... and the overall comment was "This means that after investigation and analysis of the file SophosLabs has come up to a result that the sample submitted is not malicious, not showing any malicious behaviour and properties."

    I don't know what else to do here.  I opened a support case on this issue earlier in October.  After about 4 days I finally talked to a tech and he went down the workaround route for the issue for the time being, which I have done.  That case (04447658) was then closed.

    It seems pretty straightforward here to me.  Someone at Sophos Labs needs to go back and see what changes were made in the 18.18.56 IPS/App signatures on 9/23 and roll them back with respect to NTP traffic on UDP/123 and Thunder VPN.  Why someone would blanket presume that well known UDP port 123 NTP traffic was Thunder VPN is beyond me.  I have multiple client devices on my network unable to get NTP updates with this issue present.  I have Apple products, I have Microsoft products, I have other IoT devices, I have Hikvision security cameras.  Heck, I can reproduce this AT WILL with my Apple MacBook Pro laptop.  There is no Thunder VPN in my network.  My Hikvision cameras do not have Thunder VPN on them.  But yet all ~35 endpoints on my network can't get NTP updates with this IPS/App filter post 18.18.56.

    Feel free to take these two case numbers back internally and see what else you can do.  I appreciate the help as I don't know what else I can as a support paying Sophos XG customer.  But I'll tell you, this support experience (frankly it's my first real one) isn't leaving me with a positive impression.

  • Did you create a Submission or a Application Control Submission?
    BTW: ThunderVPN uses Port 123 to connect. It is a cheap way to hide behind port based app controls. 

  • I submitted it as "Application Control" ... was that incorrect?  Should I choose "Sample File" instead?  Thanks for the added info on how Thunder VPN uses ports.  

  • I have the same problem with detection as "Thunder VPN", however, it happens to me with HCL Notes clients, which normally communicate only via port 1352. Due to the fact that "Thunder VPN" is also blocked in the application control, I have massive problems with the Notes clients, partly because of this error no attachments can be saved from the e-mails or mail boxes can not be opened, because the connection breaks. I have now temporarily allowed "Thunder VPN" in the application control, so the problems are gone for now, but this can only be a workaround. I hope that this bug will be fixed as soon as possible.

  • OK I have been watching this thread for a while as we have also been getting these blocked Thunder VPN connections on our XG fw. These began on the 24th Sept 21 and previous to this we had been getting blocked Tunnelbear (VPN) reports.


    On our system honing in on the culprit seems to have been a bit easier than some other here as these connections have been predictable over the last weeks and once a day at specific times to only 2x servers, both web servers running very few non standard extra packages.


    My immediate thought was to check the LetsEncrypt "CertifyTheWeb" app, so I disabled it in services and sure enough, last night there was no blocked Thunder VPN connection:

    The question remains, why is a supposedly legit app (we use it to update our site certs) using some iffy Android VPN service and connecting behind port 123 to a bunch of IP addresses worldwide (most have no entry on AbuseIP although one did route direct to an embedded player with no content! Highly suspicious and suggests to me something is awry.

     

    If you need any more info pcap or whatever, I will do my best to provide (and will be disabling CertifyTheWeb on our systems for now!)

  • I have disabled IPS and application testing on all my internal rules that were causing this error. Interestingly the NTP does not suffer this issue when accessing external NTP servers.

    Ian

  • As per my post above https://community.sophos.com/sophos-xg-firewall/f/discussions/129054/any-experience-with-an-excessive-number-of-thundervpn-hits/479924#479924 (I'm posting on the end of this thread to keep it visible as recent) we have now disabled the Let's Encrypt's Certify The Web apps service on both the web servers that it was installed on, and there have been no further logs of Thunder VPN since. 
    I am very much hoping this is simple a false positive and that it's not some exploited vulnerability in the cert renewal app/service, we have to renew our certs manually anyway (afaik this can't integrate with XG to automate the process) so until further notice, offending services will remain disabled and our issue is resolved. I will be interested to see whether others are not CertifyTheWeb users still get this appearing in their logs....

    [EDIT] coincidentally, it seems, there was a pattern update (IPS and Application signatures: 18.18.61 21:12:10, Oct 12 2021) the same day I disabled the suspected service so what are the chances the fix came at the same time we disabled the suspected service?? Re-enabling the service to confirm!

  • I re-enabled my ips and application classification earlier today to see if the new pattern has any affect.

    ian