search

toralf / torutils

Few tools for a Tor relay.
https://zwiebeltoralf.de/torserver.html
GNU General Public License v3.0
45 stars 7 forks source link

ipv4-rules.sh makes ORPort unreachable #1

Closed o-alquimista closed 2 years ago

o-alquimista commented 2 years ago

During the relay initialization I can see in the notice log file that Tor was unable to confirm ipv4 to be reachable. Only ipv6 is confirmed reachable.

Aug 02 22:59:06.000 [notice] Now checking whether IPv4 ORPort 143.208.84.100:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Aug 02 22:59:06.000 [notice] Now checking whether IPv6 ORPort [2804:2aec:205:4600:dea6:32ff:fe9c:c7ca]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Aug 02 23:00:09.000 [notice] Self-testing indicates your ORPort [2804:2aec:205:4600:dea6:32ff:fe9c:c7ca]:9001 is reachable from the outside. Excellent.
Aug 02 23:18:06.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at 143.208.84.100:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Steps to reproduce:

Console output

$ sudo bash ipv4-rules.sh start
grep: /sys/module/xt_recent/parameters/ip_list_tot: File or directory not found
ip_list_tot of kernel module 'recent' is not set to max

iptables list (with script started)

$ sudo iptables --list INPUT
Chain INPUT (policy DROP)
target     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere             tcp flags:!FIN,SYN,RST,ACK/SYN state NEW /* ter 02 ago 2022 22:55:55 -03 */
ACCEPT     all  --  anywhere             anywhere            
           tcp  --  anywhere             143.208.84.100.dipelnet.com.br  tcp dpt:9001 flags:FIN,SYN,RST,ACK/SYN recent: SET name: tor-ddos-9001 side: source mask: 255.255.255.255
SET        tcp  --  anywhere             143.208.84.100.dipelnet.com.br  tcp dpt:9001 flags:FIN,SYN,RST,ACK/SYN recent: UPDATE seconds: 300 hit_count: 15 TTL-Match name: tor-ddos-9001 side: source mask: 255.255.255.255 add-set tor-ddos src exist
SET        tcp  --  anywhere             143.208.84.100.dipelnet.com.br  tcp dpt:9001 #conn src/32 > 3 add-set tor-ddos src exist
ACCEPT     tcp  --  anywhere             143.208.84.100.dipelnet.com.br  tcp dpt:9001 match-set tor-authorities src
DROP       tcp  --  anywhere             anywhere             match-set tor-ddos src
ACCEPT     tcp  --  anywhere             143.208.84.100.dipelnet.com.br  tcp dpt:9001
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere             ctstate INVALID
ACCEPT     tcp  --  anywhere             server1.lan          tcp dpt:ssh
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request limit: avg 6/sec burst 5
DROP       icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     tcp  --  anywhere             143.208.84.100.dipelnet.com.br  tcp dpt:https
ACCEPT     tcp  --  anywhere             143.208.84.100.dipelnet.com.br  tcp dpt:http

If I stop ipv4-rules.sh and restart the relay, Tor will eventually confirm that it is reachable. I've tested this multiple times and it is consistent. ipv6-rules.sh works without any problems.

toralf commented 2 years ago

Hhm, the rules looks fine.

If you add -n to the iptables list, does it show the right ip address ?

What does the ipset list -t show ?

BTW a (hopefully cosmetic) issue, it seems that your recent kernel module is named differently then here. May I ask what you get for tail -v /sys/module/*/parameters/ip_list_to' ?

Update: What happened if you change iptables -P INPUT DROP into iptables -P INPUT ACCEPT? Background: Either a rule actively drops packets or packets are not accepted for any reason. In the first case the ACCEPT won't help, in the later however.

o-alquimista commented 2 years ago 
$ sudo iptables --list INPUT -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW /* qua 03 ago 2022 09:32:43 -03 */
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
           tcp  --  0.0.0.0/0            143.208.84.100       tcp dpt:9001 flags:0x17/0x02 recent: SET name: tor-ddos-9001 side: source mask: 255.255.255.255
SET        tcp  --  0.0.0.0/0            143.208.84.100       tcp dpt:9001 flags:0x17/0x02 recent: UPDATE seconds: 300 hit_count: 15 TTL-Match name: tor-ddos-9001 side: source mask: 255.255.255.255 add-set tor-ddos src exist
SET        tcp  --  0.0.0.0/0            143.208.84.100       tcp dpt:9001 #conn src/32 > 3 add-set tor-ddos src exist
ACCEPT     tcp  --  0.0.0.0/0            143.208.84.100       tcp dpt:9001 match-set tor-authorities src
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            match-set tor-ddos src
ACCEPT     tcp  --  0.0.0.0/0            143.208.84.100       tcp dpt:9001
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID
ACCEPT     tcp  --  0.0.0.0/0            192.168.1.106        tcp dpt:22
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 6/sec burst 5
DROP       icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8
ACCEPT     tcp  --  0.0.0.0/0            143.208.84.100       tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            143.208.84.100       tcp dpt:80
$ sudo ipset list -t
Name: tor-authorities
Type: hash:ip
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0x59356b46
Size in memory: 640
References: 1
Number of entries: 11

Name: tor-ddos
Type: hash:ip
Revision: 5
Header: family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0x5bd7d95b
Size in memory: 200
References: 3
Number of entries: 0

Name: tor-authorities6
Type: hash:ip
Revision: 5
Header: family inet6 hashsize 1024 maxelem 65536 bucketsize 12 initval 0x74122724
Size in memory: 656
References: 1
Number of entries: 7

Name: tor-ddos6
Type: hash:ip
Revision: 5
Header: family inet6 hashsize 1024 maxelem 65536 bucketsize 12 initval 0xe6e26be4
Size in memory: 208
References: 3
Number of entries: 0
$ sudo tail -v /sys/module/*/parameters/ip_list_tot
==> /sys/module/xt_recent/parameters/ip_list_tot <==
100

When I set sudo iptables -P INPUT ACCEPT (with ipv4-rules.sh started) and restart the relay, it becomes reachable.

toralf commented 2 years ago

Ok, so a missing ACCEPT line. Cannot find the culprit now.

Nevertheless:

The recent list is too small, pls follow https://tldrtips.com/raising-the-limit-for-xt_recent-iptables-module/ to enlarge it to 10000. I do wonder why you run into grep: /sys/module/xt_recent/parameters/ip_list_tot: File or directory not found whilst the tail works.? Update: I fixed the warning in 96a557f

It seems that tor-ddos and tor-ddos6 do miss the "timeout" value. Please stop the script, run rm /var/tmp/ipset.tor-ddos* and start it.

And finally, please run iptables -nv -L INPUT to have the stats.

o-alquimista commented 2 years ago

I've appended iptables -P INPUT ACCEPT to addTor(). Is that ok? Doesn't that invalidate the previous DROP rules?

$ sudo iptables -nv -L INPUT
Chain INPUT (policy ACCEPT 3095 packets, 188K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   58 34104 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW /* qua 03 ago 2022 10:44:43 -03 */
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0            tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 flags:0x17/0x02 recent: SET name: tor-ddos-9001 side: source mask: 255.255.255.255
    0     0 SET        tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 flags:0x17/0x02 recent: UPDATE seconds: 300 hit_count: 15 TTL-Match name: tor-ddos-9001 side: source mask: 255.255.255.255 add-set tor-ddos src exist
    0     0 SET        tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 #conn src/32 > 3 add-set tor-ddos src exist
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 match-set tor-authorities src
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set tor-ddos src
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001
 895K  684M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
   18   952 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.106        tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 6/sec burst 5
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:80
toralf commented 2 years ago

I've appended iptables -P INPUT ACCEPT to addTor(). Is that ok? Doesn't that invalidate the previous DROP rules?

Is it not the idea for the long run, but it shows for now, that no DROP rule is wrongly firing. Instead the ACCEPT rules doesn't work as expected.

I'm wondering about the 0 pkts going to your port 9001.

o-alquimista commented 2 years ago

Well, the relay is reachable and there is some activity.

Captura de tela de 2022-08-03 12-23-28

And a lot of connections.

Captura de tela de 2022-08-03 12-23-01

$ sudo iptables -nv -L INPUT
Chain INPUT (policy ACCEPT 4407 packets, 267K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  125 77072 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW /* qua 03 ago 2022 10:44:43 -03 */
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0            tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 flags:0x17/0x02 recent: SET name: tor-ddos-9001 side: source mask: 255.255.255.255
    0     0 SET        tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 flags:0x17/0x02 recent: UPDATE seconds: 300 hit_count: 15 TTL-Match name: tor-ddos-9001 side: source mask: 255.255.255.255 add-set tor-ddos src exist
    0     0 SET        tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 #conn src/32 > 3 add-set tor-ddos src exist
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001 match-set tor-authorities src
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set tor-ddos src
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:9001
1802K 1337M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    1    40 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
   35  1956 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.106        tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 6/sec burst 5
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            143.208.84.100       tcp dpt:80
toralf commented 2 years ago

I do not have an explanation.

The "Chain INPUT (policy ACCEPT 4407 packets, 267K bytes)" shows just few packets which where ACCEPTed. So the main traffic is handled by the conntrack module. Said that the majority of your TCP connections are initiated by your relay. There're no connection from outher relays to the ORport of your relay (except probably the 4407 packets).

Your ssh port is a local address(192.168.x.x) - does this relay run by any chance behind a DSL router / NAT / etc ?

What do ip a and ip r give ?

o-alquimista commented 2 years ago

Your ssh port is a local address(192.168.x.x) - does this relay run by any chance behind a DSL router / NAT / etc ?

Yes, my router does the port redirection. It runs OpenWrt.

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:9c:c7:ca brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
       valid_lft 23026sec preferred_lft 17626sec
    inet6 fd17:3cb2:d446:0:dea6:32ff:fe9c:c7ca/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2804:2aec:205:4600:dea6:32ff:fe9c:c7ca/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 146305sec preferred_lft 120385sec
    inet6 fe80::dea6:32ff:fe9c:c7ca/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether dc:a6:32:9c:c7:cc brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:d1:76:04:81 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: br-348dee5b7b92: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:2e:86:aa:45 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-348dee5b7b92
       valid_lft forever preferred_lft forever
    inet6 fe80::42:2eff:fe86:aa45/64 scope link 
       valid_lft forever preferred_lft forever
23: veth69d9314@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-348dee5b7b92 state UP group default 
    link/ether 06:3a:91:80:f9:db brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet 169.254.157.221/16 brd 169.254.255.255 scope global noprefixroute veth69d9314
       valid_lft forever preferred_lft forever
    inet6 fe80::43a:91ff:fe80:f9db/64 scope link 
       valid_lft forever preferred_lft forever
25: vethe21e1cf@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-348dee5b7b92 state UP group default 
    link/ether 72:ab:11:20:fe:45 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.128.173/16 brd 169.254.255.255 scope global noprefixroute vethe21e1cf
       valid_lft forever preferred_lft forever
    inet6 fe80::70ab:11ff:fe20:fe45/64 scope link 
       valid_lft forever preferred_lft forever
$ ip r
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.106 metric 202 
169.254.0.0/16 dev veth69d9314 scope link src 169.254.157.221 metric 223 
169.254.0.0/16 dev vethe21e1cf scope link src 169.254.128.173 metric 225 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.19.0.0/16 dev br-348dee5b7b92 proto kernel scope link src 172.19.0.1 
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.106 metric 202
toralf commented 2 years ago

Ok, so we have router and bridges and private LANs in the game too. May I ask how you configured your Tor relay ? Eg. I do have the address explicitely specified:


...
Nickname toralf
Address 65.21.94.13
OutboundBindAddress 65.21.94.13
OutboundBindAddress [2a01:4f9:3b:468e::13]
ORPort  65.21.94.13:443
ORPort  [2a01:4f9:3b:468e::13]:443
...
...
for the simple reason that the OR address is the 2nd IP address at my server (`scope global secondary enp8s0`). Maybe prepending the IP address to the ORport at your side helps ? ANf what I do wonder is whether the Tor traffic shown in your nyx output maybe is mostly IPv6 ?
o-alquimista commented 2 years ago

I wasn't specifying the IP addresses for the ORPort, but I just added them.

Before:

ORPort 9001

Now:

ORPort 143.208.84.100:9001
ORPort [2804:2aec:205:4600:dea6:32ff:fe9c:c7ca]:9001

Address and OutboundBindAddress are not specified.

Interestingly, it fails to start:

tor[7070]: Aug 03 20:51:07.695 [warn] Could not bind to 143.208.84.100:9001: Cannot assign requested address
tor[7070]: Aug 03 20:51:07.695 [notice] Opened OR listener connection (ready) on [2804:2aec:205:4600:dea6:32ff:fe9c:c7ca]:9001
tor[7070]: Aug 03 20:51:07.695 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.

It fails to bind to the public ipv4. I don't understand why. The address is correct, and is considered reachable when unspecified.

toralf commented 2 years ago

It fails to bind to the public ipv4. I don't understand why. The address is correct, and is considered reachable when unspecified.

Try both config entries, stop/start Tor, inspect the network connections to see, to which ip address:port Tor does bind (ss and lsof are good helper tools) and so on. Maybe people #tor and #tor-relays can give help too. And maybe removing --destination $oraddr from the rules could tell you, if another destination receives the :9001 traffic.

toralf commented 2 years ago

I wasn't specifying the IP addresses for the ORPort, but I just added them. ORPort 143.208.84.100:9001 ORPort [2804:2aec:205:4600:dea6:32ff:fe9c:c7ca]:9001

Did you managed to get this working ?

o-alquimista commented 2 years ago

Not yet. My relay is down because I'm trying to fix another problem with my connection. I'll report when it's working again.

o-alquimista commented 2 years ago

ipv4 is working now:

ORPort 143.208.84.100:9001 NoListen
ORPort 192.168.1.106:9001 NoAdvertise

Address 143.208.84.100
toralf commented 2 years ago

ipv4 is working now:

ORPort 143.208.84.100:9001 NoListen
ORPort 192.168.1.106:9001 NoAdvertise

Address 143.208.84.100

From the above I'd bet that relays="192.168.1.106:9001" should work with 84fdbff9580.

o-alquimista commented 2 years ago

Is this the output you were expecting?

$ sudo iptables -nv -L INPUT
Chain INPUT (policy DROP 1242 packets, 409K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  413  238K DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW
 1660  218K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  28M   15G ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.106        tcp dpt:9001
  11M 7307M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443

I'm no longer having problems with the relay.

However, your script is outputting a lot of messages on start. I'm using commit 6967035080953f6f700bef99c79906614381cd1a.

$ sudo bash /opt/torutils/ipv4-rules.sh start
iptables v1.8.7 (nf_tables): Couldn't load match `comment':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.8.7 (nf_tables): Couldn't load match `limit':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
ipset v7.10: Kernel error received: Invalid argument
iptables v1.8.7 (nf_tables): Couldn't load match `set':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.8.7 (nf_tables): Couldn't load match `hashlimit':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.8.7 (nf_tables): Couldn't load match `connlimit':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.8.7 (nf_tables): Couldn't load match `set':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.8.7 (nf_tables): Couldn't load match `connlimit':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

Here's the output with set -x: start.log

toralf commented 2 years ago

Your kernel lacks capabilities. Did you compiled it yourself ? The you need at least CONFIG_IP_SET, CONFIG_NETFILTER_XT_MATCH_CONNLIMIT, CONFIG_NETFILTER_XT_MATCH_COMMENT, CONFIG_NETFILTER_XT_SET, CONFIG_NETFILTER_XT_MATCH_HASHLIMIT and CONFIG_IP_SET_HASH_IP.

o-alquimista commented 2 years ago

I did not. It's the default kernel from Raspberry Pi OS (arm64).

toralf commented 2 years ago

Then you'd have to ask in a Rasberry channel how to get that functionality. Currently the ddos filter of the script is not activated accordingly to the output of iptables.

o-alquimista commented 2 years ago

Then you'd have to ask in a Rasberry channel how to get that functionality. Currently the ddos filter of the script is not activated accordingly to the output of iptables.

Will do. Is this a new requirement, or was it there all along? Previous versions of your script were running fine in this very same installation.

toralf commented 2 years ago

Then you'd have to ask in a Rasberry channel how to get that functionality. Currently the ddos filter of the script is not activated accordingly to the output of iptables.

Will do. Is this a new requirement, or was it there all along?

At least the ipset worked for you previously, that I do not understood. Hopefully the Rasberry people might have an answer.

toralf commented 2 years ago

And because your current kernel cannot use the comment in iptables the appropriate rule to allow local traffic is not implemented. So stop that script till your kernel has the capabilities - otherwise your local traffic is blocked due to the INPUT policy DROP.

o-alquimista commented 2 years ago

Your kernel lacks capabilities. Did you compiled it yourself ? The you need at least CONFIG_IP_SET, CONFIG_NETFILTER_XT_MATCH_CONNLIMIT, CONFIG_NETFILTER_XT_MATCH_COMMENT, CONFIG_NETFILTER_XT_SET, CONFIG_NETFILTER_XT_MATCH_HASHLIMIT and CONFIG_IP_SET_HASH_IP.

So, my kernel was compiled with all those capabilities. My guess now is that I messed my installation somehow. I'll try a clean reinstall.

toralf commented 2 years ago

I do wonder if the current version of the script works for you ?

o-alquimista commented 2 years ago

I'll try it again soon. For now the relay is operating well without the script.