Any experience with an excessive number of ThunderVPN hits?

As i am still not able to find any reliable source of this ThunderVPN Traffic: 

I need a pcap of this traffic and a matching conntrack of this traffic:

tcpdump -ni any port 123 -b -w /tmp/thundervpn.pcap 

conntrack -L | grep 123 

As i am still not able to find any reliable source of this ThunderVPN Traffic: 

I need a pcap of this traffic and a matching conntrack of this traffic:

tcpdump -ni any port 123 -b -w /tmp/thundervpn.pcap 

conntrack -L | grep 123 

I will try again and leave the capture running for about 10 or so minutes.

conntrack did not return any results last time.

ian

Try another shell at the same time with conntrack -E |grep 123 

And put the ips into debug mode: service ips:debug -ds nosync 

Send me the ips.log as well. 

Conctrack -E | grep 123 returns this

DESTROY] proto=udp      proto-no=17 orig-src=10.10.10.5 orig-dst=139.99.222.72 
orig-sport=123 orig-dport=123 packets=1 bytes=76 reply-src=139.99.222.72 reply-d
st=124.187.248.41 reply-sport=123 reply-dport=123 packets=1 bytes=76 mark=0x8003
 id=252905024 masterid=0 devin=Port3 devout=Port4 nseid=0 ips=11 sslvpnid=0 webf
ltid=1 appfltid=11 icapid=0 policytype=2 fwid=48 natid=7 fw_action=1 bwid=0 appi
d=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload=0xc sigoffload=0 inzone=1 outzo
ne=2 devinindex=7 devoutindex=8 hb_src=1 hb_dst=0 flags0=0x108008000a20000a flag
s1=0xd0020a00010 flagvalues=1,3,21,25,27,43,55,60,68,85,87,93,104,106,107 catid=
0 user=59 luserid=31 usergp=64 hotspotuserid=0 hotspotid=0 dst_mac=30:5a:3a:c8:3
c:3d src_mac=dc:a6:32:a5:f2:02 startstamp=1629192418 microflow[0]=INVALID microf
low[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=8 tlsruleid
=0 ips_nfqueue=0 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=1889 cur
rent_state[1]=1889 vlan_id=0 inmark=0x0 brinindex=0 sessionid=738 sessionidrev=2
5337 session_update_rev=1 dnat_done=0 upclass=0:0 dnclass=0:0 pbrid_dir0=0 pbrid
_dir1=0 nhop_id[0]=65535 nhop_id[1]=65535 nhop_rev[0]=0 nhop_rev[1]=0 conn_fp_id
=NOT_OFFLOADED                         
This extract is for the NTP server talking to the world which is never an issue.

 [UPDATE] proto=udp      proto-no=17 timeout=59 orig-src=10.10.10.30 orig-dst=16
2.159.200.1 orig-sport=33823 orig-dport=123 reply-src=10.10.10.5 reply-dst=10.10
.10.1 reply-sport=123 reply-dport=33823 [ASSURED] id=1617832768 masterid=0 devin
=Port3 devout=Port3 nseid=0 ips=11 sslvpnid=0 webfltid=1 appfltid=11 icapid=0 po
licytype=2 fwid=39 natid=6 fw_action=1 bwid=0 appid=0 appcatid=0 hbappid=0 hbapp
catid=0 dpioffload=0xc sigoffload=0 inzone=1 outzone=1 devinindex=7 devoutindex=
7 hb_src=1 hb_dst=0 flags0=0x8000a200008 flags1=0xd0020a00010 flagvalues=3,21,25
,27,43,68,85,87,93,104,106,107 catid=0 user=50 luserid=34 usergp=16 hotspotuseri
d=0 hotspotid=0 dst_mac=30:5a:3a:c8:3c:3d src_mac=24:5e:be:13:90:57 startstamp=1
629192435 microflow[0]=INVALID microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ip
spid=0 diffserv=0 loindex=7 tlsruleid=0 ips_nfqueue=1 sess_verdict=0 gwoff=0 clu
ster_node=0 current_state[0]=1889 current_state[1]=1889 vlan_id=0 inmark=0x0 bri
nindex=0 sessionid=537 sessionidrev=54603 session_update_rev=1 dnat_done=3 upcla
ss=0:0 dnclass=0:0 pbrid_dir0=0 pbrid_dir1=0 nhop_id[0]=65535 nhop_id[1]=65535 n
hop_rev[0]=0 nhop_rev[1]=0 conn_fp_id=NOT_OFFLOADED 

This one is from a QNAP NAS.

This a logviewer extract of the same transactions I hope.


That is part of the logviewer report. I will send the other files in a PM shortly.
Ian

Dumb question how to turn off IPS debug? I assume debug is still running because permission is denied to copy the file.

repeat the same command to disable debug

XG430_WP02_SFOS 18.0.5 MR-5-Build586# service -S |grep ips
ips                  RUNNING,DEBUG

Thank you, I had assumed so, but was not able to access the file, hence the question.

ian

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!)