Menu
What's new
By:
Filters Better Search

Skynet Skynet - Router Firewall & Security Enhancements

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

john9527 said:
I'd also check the default filter table. One thought I had is that Skynet may somehow be fighting with the ASUS 'Protection Server' code (which is now closed source).
Click to expand...
@john -- Are you referring to the "AIProtect" stuff here? I normally have that OFF except for the "Vulnerability Protection" piece. So I turned that OFF as well and tried again... Still have same issue as described before, i.e., Amazon Echo briefing fails when Skynet is active (with or without any blocking rules), and succeeds when Skynet is disabled. Bizarre..... But there has to be a reason!
 
ScottW said:
@john -- Are you referring to the "AIProtect" stuff here? I normally have that OFF except for the "Vulnerability Protection" piece. So I turned that OFF as well and tried again... Still have same issue as described before, i.e., Amazon Echo briefing fails when Skynet is active (with or without any blocking rules), and succeeds when Skynet is disabled. Bizarre..... But there has to be a reason!
Click to expand...
No, what I was referring to is different.....it's part of ASUS's own DoS protection.

But this looks like it may be another case of the nebulous definition of what is really an INVALID state. IIRC there was a discussion on this in the past where INVALID state checking was interfering with another router function (I think it was OpenVPN). At that time, I think we removed one of the INVALID state checks.
 
john9527 said:
No, what I was referring to is different.....it's part of ASUS's own DoS protection.

But this looks like it may be another case of the nebulous definition of what is really an INVALID state. IIRC there was a discussion on this in the past where INVALID state checking was interfering with another router function (I think it was OpenVPN). At that time, I think we removed one of the INVALID state checks.
Click to expand...
Yeah, something like that perhaps.... Maybe an incorrect sequence opening the new connection, causing an unexpected packet, which is ignored or retried when Skynet isn't active -- but dropped or causes connection to be closed when Skynet rules are active.

It would not surprise me at all if the Amazon device is doing something "unexpected" (or even incorrect) with it's connections. All I know at this point -- whatever it is -- it succeeds when Skynet is disabled, but fails when Skynet is enabled (even when no blocking is defined, so it isn't an IP being blocked).

Disabling Skynet isn't the solution I want, though! :)
 
ScottW said:
Ok... I deleted all blocking rules from Skynet, but have it active:
Code: 
Router Model; RT-AC88U
Skynet Version; v6.0.4 (23/03/2018)
iptables v1.4.14 - (eth0 @ 192.168.1.1)
ipset v6.32, protocol version: 6
FW Version; 380.69_0 (Dec 11 2017) (2.6.36.4brcmarm)
Install Dir; /tmp/mnt/ASUS/skynet (13.3G / 14.4G Space Available)
SWAP File; /tmp/mnt/ASUS/myswap.swp (256.3M)
Boot Args; /jffs/scripts/firewall start skynetloc=/tmp/mnt/ASUS/skynet

0 IPs / 0 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked!
Next, I did an iptables -Z to zero counters.

Then I reproduced the problem several times, running "iptables -nvL" (per John's tip) to see what counters (if any) were incrementing. Finally, I ran "iptables --line -t -raw -vnL" per Adamm's instruction.

The "iptables -nvL" identifies some entries entries added to the "logdrop" chain by skynet being incremented each time the problem occurs:
Code: 
Chain logdrop (8 references)
 pkts bytes target     prot opt in     out     source               destination       
   33  5640 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            match-set Skynet-Whitelist src
    3   124 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443,143,993,110,995,25,465 state INVALID
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 11
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 3
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x19
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x11
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x04
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x14
    3   124            all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            recent: SET name: TRACKINVALID side: source
    0     0 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source LOG flags 7 level 4 prefix "[BLOCKED - NEW BAN] "
    0     0 SET        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source add-set Skynet-Master src
    3   124 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

The output from "iptables --line -t -raw -vnL" after all that was:
Code: 
admin@ASUS88U:/tmp/mnt/ASUS# iptables --line -t raw -vnL
Chain PREROUTING (policy ACCEPT 64696 packets, 80M bytes)
num   pkts bytes target     prot opt in     out     source               destination       
1        0     0 LOG        all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst LOG flags 7 level 4 prefix "[BLOCKED - OUTBOUND] "
2        0     0 DROP       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist dst match-set Skynet-Master dst
3        0     0 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src LOG flags 7 level 4 prefix "[BLOCKED - INBOUND] "
4        0     0 DROP       all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ! match-set Skynet-Whitelist src match-set Skynet-Master src

All way beyond my understanding of iptables.... All help appreciated!
Click to expand...


The only other point a packet would be dropped is the following rule;

Code: 
 3   124 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443,143,993,110,995,25,465 state INVALID

But even if that were the case, the packet would have been dropped anyway with default rules (I specifically only drop packets on these ports to prevent false positives with autobanning).

Do you still have issues after running the "unban all" command?
 
Adamm said:
The only other point a packet would be dropped is the following rule;

Code: 
 3   124 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443,143,993,110,995,25,465 state INVALID

But even if that were the case, the packet would have been dropped anyway with default rules (I specifically only drop packets on these ports to prevent false positives with autobanning).

Do you still have issues after running the "unban all" command?
Click to expand...
Yes, exactly the same. After running "firewall unban all", the problem persists. Every time. Then after "9-Temporarily Disable", it works perfectly. Time after time. Then "8-Restart Skynet" and it fails again. Every time.

It doesn't make sense... But even with no bans/blocks, something is different in how the connections are treated when those rules are in place. Making no other changes, the problem 100% follows enabling Skynet, and 100% goes away when Skynet is disabled.
 
john9527 said:
@ScottW

Can you post the full 'iptables -nvL' output?
Click to expand...

Yes -- I cleared again with "iptables -Z", then duplicated the problem, then "iptables -nvL" produces this:

Code: 
admin@ASUS88U:/tmp/home/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
    0     0 logdrop    icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  507 53927 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
   11  1524 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
  148 27958 PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0           
  504 82477 PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
  504 82477 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
  120 19630 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
   25  8208 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    3   120 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 124K  175M ipttolan   all  --  *      br0     0.0.0.0/0            0.0.0.0/0           
43632 2491K iptfromlan  all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
 167K  178M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0           
    0     0 logdrop    all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0           
    0     0 logdrop    all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0           
  124 16232 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
  124 16232 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 631 packets, 133K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain ACCESS_RESTRICTION (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain FUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT_ICMP (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain NSFW (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PControls (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain PTCSRVLAN (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain PTCSRVWAN (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain SECURITY (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
    0     0 logdrop    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
    0     0 logdrop    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
    0     0 logdrop    icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain iptfromlan (1 references)
 pkts bytes target     prot opt in     out     source               destination         
43632 2491K RETURN     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan 
    0     0 RETURN     all  --  *      tun21   0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan 

Chain ipttolan (1 references)
 pkts bytes target     prot opt in     out     source               destination         
 124K  175M RETURN     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan 
    0     0 RETURN     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan 

Chain logaccept (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain logdrop (8 references)
 pkts bytes target     prot opt in     out     source               destination         
    9  1440 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            match-set Skynet-Whitelist src
    2    84 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443,143,993,110,995,25,465 state INVALID
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 11
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 3
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x19
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x11
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x04
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x3F/0x14
    3   120            all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            recent: SET name: TRACKINVALID side: source
    0     0 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source LOG flags 7 level 4 prefix "[BLOCKED - NEW BAN] "
    0     0 SET        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID recent: UPDATE seconds: 300 hit_count: 2 name: TRACKINVALID side: source add-set Skynet-Master src
    3   120 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
john9527 said:
@ScottW

Can you post the full 'iptables -nvL' output?
Click to expand...
And in case it is helpful.... I disabled Skynet, cleared the counters, ran the reproduction steps again (it streamed perfectly with Skynet disabled). Here is the output "iptables -nvL" after that:
Code: 
admin@ASUS88U:/tmp/home/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1194
    0     0 logdrop    icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  159 16403 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    8  1400 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
   59 10228 PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0          
  286 48222 PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0          
  286 48222 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
   45  6210 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
   12  3938 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0          
    2    80 logdrop    all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
73467  104M ipttolan   all  --  *      br0     0.0.0.0/0            0.0.0.0/0          
25544 1528K iptfromlan  all  --  br0    *       0.0.0.0/0            0.0.0.0/0          
98934  106M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0          
    0     0 logdrop    all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0          
    0     0 logdrop    all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state INVALID
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0          
   77 13388 NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
   77 13388 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT 212 packets, 25789 bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain ACCESS_RESTRICTION (0 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain FUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain INPUT_ICMP (1 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain NSFW (1 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain PControls (0 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain PTCSRVLAN (1 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain PTCSRVWAN (1 references)
 pkts bytes target     prot opt in     out     source               destination        

Chain SECURITY (0 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
    0     0 logdrop    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
    0     0 logdrop    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
    0     0 logdrop    icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain iptfromlan (1 references)
 pkts bytes target     prot opt in     out     source               destination        
25544 1528K RETURN     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan
    0     0 RETURN     all  --  *      tun21   0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan

Chain ipttolan (1 references)
 pkts bytes target     prot opt in     out     source               destination        
73467  104M RETURN     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan
    0     0 RETURN     all  --  tun21  *       0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.1.0/255.255.255.0 name: lan

Chain logaccept (0 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0          

Chain logdrop (8 references)
 pkts bytes target     prot opt in     out     source               destination        
   10  1480 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
@ScottW
Just for a test....is there a way to clear the Skynet Whitelist and re-run?

EDIT: Also, the data shows that the ASUS Protection Server isn't playing a factor.
 
john9527 said:
@ScottW
Just for a test....is there a way to clear the Skynet Whitelist and re-run?
Click to expand...
Not sure... Would need instruction from @Adamm. I can remove my (6) additions with "whitelist remove all", but that leaves the bulk of the list intact -- and some of it is required (like rules for LAN, for list distribution sites, etc.)... So not sure how to properly test.

With my (6) additions removed (via "whitelist remove all"), the problem still occurs.
 
ScottW said:
Not sure... Would need instruction from @Adamm. I can remove my (6) additions with "whitelist remove all", but that leaves the bulk of the list intact -- and some of it is required (like rules for LAN, for list distribution sites, etc.)... So not sure how to properly test.

With my (6) additions removed (via "whitelist remove all"), the problem still occurs.
Click to expand...


So if its not the bulk of Skynet blocking Alexa as indicated by "unban all" not making any difference. It seems its due to invalid packets being dropped (which would also indicate you would have similar issues without Skynet with the SPI firewall enabled).

If you run the following command while Skynet is active does it fix the issue (or better yet make logs appear?)

Code: 
iptables -D logdrop -i "eth0" -p tcp -m multiport --sports 80,443,143,993,110,995,25,465 -m state --state INVALID -j DROP
 
ScottW said:
Not sure... Would need instruction from @Adamm. I can remove my (6) additions with "whitelist remove all", but that leaves the bulk of the list intact -- and some of it is required (like rules for LAN, for list distribution sites, etc.)... So not sure how to properly test.

With my (6) additions removed (via "whitelist remove all"), the problem still occurs.
Click to expand...
The only difference I can see in Skynet vs no-Skynet, is that Skynet is ACCEPTING packets via the whitelist that would normally be DROPPED in the no- Skynet case (sort of the reverse of what you would expect). This may be making the Alexa interface behave differently.

Another way to test this (thanks @Adamm for reminding me)
Code: 
iptables -D logdrop 1
 
@ScottW

Actually better yet, if you disable "autobanning" entirely via the installer it should remove all additional rules from the logdrop chain. Then we can pretty accurately assess if those rules are the cause.
 
Adamm said:
So if its not the bulk of Skynet blocking Alexa as indicated by "unban all" not making any difference. It seems its due to invalid packets being dropped (which would also indicate you would have similar issues without Skynet with the SPI firewall enabled).
Click to expand...
Not sure what you mean... But I have the default SPI firewall ON at all times. I would never disable that. When Skynet is active, the problem with the Amazon device occurs. When Skynet is disabled (with no other changes), it works perfectly.

Adamm said:
If you run the following command while Skynet is active does it fix the issue (or better yet make logs appear?)

Code: 
iptables -D logdrop -i "eth0" -p tcp -m multiport --sports 80,443,143,993,110,995,25,465 -m state --state INVALID -j DROP
Click to expand...

With Skynet enabled (and no blocking rules), I copy/pasted that command and it ran (no errors). I then started watching the log, and reproduced the problem. No log entries were created when I reproduced the problem.

To be clear: There are log entries being displayed for other events, before and after the problem is reproduced, so logging is working (typical INBOUND port scanning stuff). But no messages happening close to when the problem is reproduced, and no Outbound blocks.
 
ScottW said:
Not sure what you mean... But I have the default SPI firewall ON at all times. I would never disable that. When Skynet is active, the problem with the Amazon device occurs. When Skynet is disabled (with no other changes), it works perfectly.



With Skynet enabled (and no blocking rules), I copy/pasted that command and it ran (no errors). I then started watching the log, and reproduced the problem. No log entries were created when I reproduced the problem.

To be clear: There are log entries being displayed for other events, before and after the problem is reproduced, so logging is working (typical INBOUND port scanning stuff). But no messages happening close to when the problem is reproduced, and no Outbound blocks.
Click to expand...


Try disable autobanning and report back.
 
Adamm said:
@ScottW

Actually better yet, if you disable "autobanning" entirely via the installer it should remove all additional rules from the logdrop chain. Then we can pretty accurately assess if those rules are the cause.
Click to expand...
Ok, re-installed and said "no" to auto-bans. So back to a "default" configuration, with Banmalware, and about 114,332 IP's / 1677 Ranges Banned.

*** I tried to reproduce the problem twice, and was unable to with "Autoban" disabled. ***

I will test some more, with and without Autobans enabled, to verify. But from this quick test, it looks like disabling autoban eliminated the issue. Will report back after doing some more tests to verify.....
 
Adamm said:
Try disable autobanning and report back.
Click to expand...
Confirmed across multiple tests... With Autoban=NO during install, the problem is gone. Install again with Autoban=YES, and the problem returns. No debug messages in either case.

john9527 said:
When you test again with Autoban enabled, please try the command I added in post #2411
Click to expand...
Not sure on sequence you wanted... But I re-installed Skynet with Autoban=YES, and verified that the problem was present again. Then I ran the command "iptables -D logdrop 1", and could not reproduce the problem after that -- just as when installed with Autoban=NO. To verify, I repeated this entire process (reinstalled with Autoban=Yes, verified problem was present, ran "iptables -D logdrop 1", problem was gone. No debug messages when watching log before or after .

So either one of (Autoban=No at install) or (Autoban=Yes at install, followed by "iptables -D logdrop 1") resolves the problem. Still not seeing any relevant debug messages when following the log, with either combination.

Please tell me what that means. :)
 
ScottW said:
or (Autoban=Yes at install, followed by "iptables -D logdrop 1") resolves the problem.
Click to expand...
You got the sequence right. My hypothesis seems to hold. Skynet is actually accepting INVALID packets that are normally dropped. Here's a better workaround command instead of the iptables delete. This will keep the whitelist active for the other chains.
Code: 
iptables -I logdrop -m state --state INVALID -j DROP
 
john9527 said:
You got the sequence right. My hypothesis seems to hold. Skynet is actually accepting INVALID packets that are normally dropped. Here's a better workaround command instead of the iptables delete. This will keep the whitelist active for the other chains.
Code: 
iptables -I logdrop -m state --state INVALID -j DROP
Click to expand...
Thanks John! I'll give that a try and report back tomorrow....

I did install tcpdump and ran it. Hard (for me) to fully understand the output, but it is easy to see a pattern where the Amazon device looks up a DNS record, initiates a connection, gets the acknowledgement, then starts streaming. It does that for each of the "news briefing" segments. When one stalls (i.e., when Skynet is active and autoban=yes), the acknowledgement never makes it to tcpdump.... So the packet (SYN ACK?) must be getting dropped somewhere. I'd blame it on the content distribution server, except it works fine with Skynet disabled (or autoban=no). So something about how iptables is identifying those packets.

Thanks for your help, I'll check back in tomorrow with further results!
 
You must log in or register to reply here.

Similar threads

W
Looking for an add-on that does...
Replies
5
Views
2K
JGrana
JGrana
Viktor Jaep
Skynet Filter Validator v0.7 - Skynet Firewall Filter List IPv4 Integrity Validator
3 4 5
Replies
83
Views
13K
SomeWhereOverTheRainBow
SomeWhereOverTheRainBow
Viktor Jaep
TAILMON TAILMON v1.0.20 -July 27, 2024- WireGuard-based Tailscale Installer, Configurator and Monitor (Now available in AMTM!)
Replies
2
Views
289
Viktor Jaep
Viktor Jaep
RMerlin
Fun with ChatGPT...
2
Replies
33
Views
2K
RMerlin
RMerlin
M
Firewall doesen't block custom rules, neighter Skynet
Replies
0
Views
1K
MamaLing
M
Similar threads
Thread starter Title Forum Replies Date
Klonoa Skynet Skynet causes router to crash and reboot Asuswrt-Merlin AddOns 1
S Skynet Skynet showing router itself making calls to China? Asuswrt-Merlin AddOns 26
J Skynet Skynet - Blocked outbounds coming from the router itself? Asuswrt-Merlin AddOns 12
O Skynet Installing Skynet causes router to crash and reboot Asuswrt-Merlin AddOns 26
L Skynet I have installed the skynet firewall how do I configure it if the security of iot devices is important? Asuswrt-Merlin AddOns 2
Davidncali001 Skynet Message on SKYNET I havent seen before Asuswrt-Merlin AddOns 1
S Skynet firewall reduces wireless range Asuswrt-Merlin AddOns 14
P Skynet Internet speed lower with Skynet on Asuswrt-Merlin AddOns 9
N Skynet SkyNet/Firewall blocking all ping requests, including outbound Asuswrt-Merlin AddOns 6
W Skynet SOLVED: Scrollbar Disappears on Skynet Tab on Asuswrt-Merlin 386.14 Asuswrt-Merlin AddOns 10

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Members online

Total: 850 (members: 23, guests: 827)
Top