Skynet WAN ip outbound blocked

[SomeWhereOverTheRainBow]

The issue is that the OP must have disabled CDN Whitelisting in Skynet, otherwise the IP would have been whitelisted by Skynet, just like in EmeraldDeer's output. OP needs to run the same command to see why it's being blocked.

firewall stats search ip 188.114.96.0

I figured that must be the case. But I was just clarifying that it is not the WAN itself IP being blocked here for EmeraldDeer confusion. JK. Actually for my own confusion at what EmeraldDeer's post was about.

@dave14305 is right..

If you turn on CDNwhitelisting, that address would be whitelisted through cloudflare entries.

ipset list | grep 188.114.96.0
188.114.96.0/20 comment "CDN-Whitelist: CloudFlare"

 

[EmeraldDeer]

If the outbound connection is not malware, then I would follow up on proper whitelisting.

If the outbound connection could be malware, then how does one prove it? Maybe tcpdump can capture it and WireShark on PC could analyze pcap. If you are lucky enough for socket to still be there, then netstat -ap could identify process on router.

 

[SomeWhereOverTheRainBow]

If the outbound connection is not malware, then I would follow up on proper whitelisting.

If the outbound connection could be malware, then how does one prove it? Maybe tcpdump can capture it and WireShark on PC could analyze pcap. If you are lucky enough for socket to still be there, then netstat -ap could identify process on router.

Do you think the OP could be running something like DNSCRYPT-Proxy or AdGuardHome on their router to access Cloudflare over DoH?

 

[EmeraldDeer]

Do you think the OP could be running something like DNSCRYPT-Proxy or AdGuardHome on their router to access Cloudflare over DoH?

I don't see Cloudflare DNS or NTP services using content distribution servers.
DoH would not have a source address of the router.
DoT would have a source address of the router but the destination port would be 853 rather than 443.

 

[SomeWhereOverTheRainBow]

I don't see Cloudflare DNS or NTP services using content distribution servers.
DoH would not have a source address of the router.
DoT would have a source address of the router but the destination port would be 853 rather than 443.

hmmm, I wonder if OP is running their own cloudflare DDNS updates (or if their ddns service provider uses cloudflare)? could that be the cause?

I think it might not hurt for the OP to check their syslog to see if any services are failing to perform updates. e.g. DDNS services.

 

[K3r1m0]

@K3r1m0

what does ipset list | grep 188.114.96.0 give you from command line? it will atleast tell you if one of your blocklists is blocking it, or if it was a ban that came from AI Protect.

Output is

188.114.96.0/20 comment "CDN-Whitelist: CloudFlare"

 

[K3r1m0]

The issue is that the OP must have disabled CDN Whitelisting in Skynet, otherwise the IP would have been whitelisted by Skynet, just like in EmeraldDeer's output. OP needs to run the same command to see why it's being blocked.

firewall stats search ip 188.114.96.0

[13] --> CDN Whitelisting           | [Enabled]

 

[K3r1m0]

The issue is that the OP must have disabled CDN Whitelisting in Skynet, otherwise the IP would have been whitelisted by Skynet, just like in EmeraldDeer's output. OP needs to run the same command to see why it's being blocked.

firewall stats search ip 188.114.96.0

Warning: 188.114.96.0 is in set Skynet-Whitelist.
188.114.96.0 is NOT in set Skynet-Blacklist.
188.114.96.0 is NOT in set Skynet-BlockedRanges.

Whitelist Reason;
 188.114.96.0/20 "CDN-Whitelist: CloudFlare"


Associated Domain(s);
sda.fyi
asn.ipinfo.app
lindasbakskola.se


[i] IP Location - Canada (CLOUDFLARENET / AS13335)

[i] 188.114.96.0 First Tracked On May 22 23:06:12
[i] 188.114.96.0 Last Tracked On May 25 14:26:34
[i] 184 Blocks Total

 

[SomeWhereOverTheRainBow]

Warning: 188.114.96.0 is in set Skynet-Whitelist.
188.114.96.0 is NOT in set Skynet-Blacklist.
188.114.96.0 is NOT in set Skynet-BlockedRanges.

Whitelist Reason;
 188.114.96.0/20 "CDN-Whitelist: CloudFlare"


Associated Domain(s);
sda.fyi
asn.ipinfo.app
lindasbakskola.se


[i] IP Location - Canada (CLOUDFLARENET / AS13335)

[i] 188.114.96.0 First Tracked On May 22 23:06:12
[i] 188.114.96.0 Last Tracked On May 25 14:26:34
[i] 184 Blocks Total

Could it be getting blocked by some other means and skynet is capturing the drop? Just random question.

 

[SomeWhereOverTheRainBow]

Warning: 188.114.96.0 is in set Skynet-Whitelist.
188.114.96.0 is NOT in set Skynet-Blacklist.
188.114.96.0 is NOT in set Skynet-BlockedRanges.

Whitelist Reason;
 188.114.96.0/20 "CDN-Whitelist: CloudFlare"


Associated Domain(s);
sda.fyi
asn.ipinfo.app
lindasbakskola.se


[i] IP Location - Canada (CLOUDFLARENET / AS13335)

[i] 188.114.96.0 First Tracked On May 22 23:06:12
[i] 188.114.96.0 Last Tracked On May 25 14:26:34
[i] 184 Blocks Total

It would be nice if we could figure out more information, for all we know the ip that is being blocked could reside outside the range of ips for that specific subnet of /20 and we cannot tell that. This is definitely starting to sound more like a malware with these types of behaviors...

Can you ping any of the ip addresses in the range above from your router?

 

[K3r1m0]

If the outbound connection is not malware, then I would follow up on proper whitelisting.

If the outbound connection could be malware, then how does one prove it? Maybe tcpdump can capture it and WireShark on PC could analyze pcap. If you are lucky enough for socket to still be there, then netstat -ap could identify process on router.

Is it possible to run wireshark on the router itself, or do you mean on my workstation?

 

[SomeWhereOverTheRainBow]

Is it possible to run wireshark on the router itself, or do you mean on my workstation?
The only startling line I can find for "netstat -ap" is:

tcp       32      0 xxx.xxx.xxx:42399    a23-60-30-167.deploy.static.akamaitechnologies.com:https CLOSE_WAIT  2246/wred

You can tcpdump some of the packets on the router to a .pcap file. Move the .pcap file to a workstation with winscp, and then inspect the .pcap file from a workstation using Wireshark.

 

[dave14305]

Could it be getting blocked by some other means and skynet is capturing the drop? Just random question.

No, the log message is using Skynet’s custom prefix, so it must have been in the blocklist at one point AND missing from the whitelist.

 

[dave14305]

asn.ipinfo.app

This name is used within Skynet to lookup and download ASN info. So no harm, no foul.

 

[SomeWhereOverTheRainBow]

No, the log message is using Skynet’s custom prefix, so it must have been in the blocklist at one point AND missing from the whitelist.

Makes sense. Is there any point this list would not be loaded during skynets startup or update processes? I looked at the code and I didn't see any places, but I could be wrong. Skynet is a pretty lengthy script. If such a grey area exists inside the script, then retrieval of any whitelistings could fall prey to a blocklist entry.

 

[dave14305]

Makes sense. Is there any point this list would not be loaded during skynets startup or update processes? I looked at the code and I didn't see any places, but I could be wrong. Skynet is a pretty lengthy script.

Well, you wrote the modifications to the curl commands that download the Cloudflare list, among others. Was it an improvement?

It’s still not clear how the IP ended up on the blocklist, but it’s water under the bridge now.

 

[SomeWhereOverTheRainBow]

Well, you wrote the modifications to the curl commands that download the Cloudflare list, among others. Was it an improvement?

It’s still not clear how the IP ended up on the blocklist, but it’s water under the bridge now.

Definitely an improvement, but I am trying to figure how the IP ended up in the blocklist. That is why I asked if you noticed any where in the script where the whitelist might not have been applied before blocklisting has already started. If such a grey area exists inside the script, then retrieval of any whitelistings could fall prey to a blocklist entry.

 

[SomeWhereOverTheRainBow]

This name is used within Skynet to lookup and download ASN info. So no harm, no foul.

FYI, the IP must vary geographically for that domain

RT-AX88U_Pro-29B8:/tmp/home/root# nslookup asn.ipinfo.app 2>/dev/null | awk '/^Address[[:space:]][0-9]*\:[[:space:]]/{if($3 ~ /^([0-9]{1,3}\.){3}[0-9]{1,3}/ && NR > 2)print $3}'
104.21.73.151
172.67.190.83

But like you said,

it’s all water under the bridge now.

; and, if it is skynet blocking itself by some glitch in its own loading logic or order of commands, then

no harm, no foul.

Great efficacy.

 

[SomeWhereOverTheRainBow]

Well, you wrote the modifications to the curl commands that download the Cloudflare list, among others. Was it an improvement?

It’s still not clear how the IP ended up on the blocklist, but it’s water under the bridge now.

The only place I can see a flaw is right at this spot...

https://github.com/Adamm00/IPSet_ASUS/blob/master/firewall.sh#L872

here we are deleting the CDN whitelist entries out of the IPset, before downloading the new one; however, this line of code is not my brain child. This is the only place I could see where the entry is deleted. before a curl to download the ASN is made. Thus explaining why the users skynet blocked the IP address for asn.ipinfo.app in their geographical region.

@dave14305

what about this line as well?

https://github.com/Adamm00/IPSet_ASUS/blob/master/firewall.sh#L3800

If you notice we are deleting whitelist entries after having already loaded some, including the CDN.

        Whitelist_Extra
        Whitelist_CDN
        Whitelist_VPN
        sed '\~add Skynet-Whitelist ~!d;\~nvram: ~!d;s~ comment.*~~;s~add~del~g' "$skynetipset" | ipset restore -!
        Whitelist_Shared

 

[Viktor Jaep]

The only place I can see a flaw is right at this spot...

https://github.com/Adamm00/IPSet_ASUS/blob/master/firewall.sh#L872

here we are deleting the CDN whitelist entries out of the IPset, before downloading the new one; however, this line of code is not my brain child. This is the only place I could see where the entry is deleted. before a curl to download the ASN is made. Thus explaining why the users skynet blocked the IP address for asn.ipinfo.app in their geographical region.

@dave14305

what about this line as well?

https://github.com/Adamm00/IPSet_ASUS/blob/master/firewall.sh#L3800

If you notice we are deleting whitelist entries after having already loaded some, including the CDN.

        Whitelist_Extra
        Whitelist_CDN
        Whitelist_VPN
        sed '\~add Skynet-Whitelist ~!d;\~nvram: ~!d;s~ comment.*~~;s~add~del~g' "$skynetipset" | ipset restore -!
        Whitelist_Shared

Sounds like Skynet 7.4.2 will be available here pretty soon!