I already created a topic in the german subforum, but I cannot find my post anywhere, not in my profile, not in the topic list (You have no activity yet.), so cannot delete it. So just creating an additional one here.
closed = not filtered and not listening
filtered = rejected/dropped by fw, regardless of listen state
BTW, global permissive INPUT is not very useful. A good practice is to drop incoming by default while a) allowing only necessary services and b) maintaining states (WARNING: use with understanding, otherwise you'll be disconnected):
...
# drop all incoming
iptables -P INPUT DROP
# allow necessary ports
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dport 80,443 -j ACCEPT
# allow all on lo if
iptables -A INPUT -i lo -j ACCEPT
# do not disconnect current and accept response from outgoing connections
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
...
It is only accessible from my local network, why would I need to use a DROP policy?
Local address space does not necessary mean safe. Malicious script in browser can query sites on local network or untrusted program could inspect the network (Steam is doing this for example, and it's known to contain exploits.). Sure, your wifi with untrusted devices and applications is also on the same address space.
As of v4.0, this should no longer be a problem unless you choose to deviate from the new default blocking mode 949 and return to the IP-based mode 154. And the iptables rules mentioned in this article should not be needed.
So your problem is not there most likely. What's happening exactly? What's the environment? Is this a clean install? Try other blocking modes as well.
pi@ph5:~ $ man nmap
[..]
The output from Nmap is a list of scanned targets, with
supplemental information on each depending on the options used.
Key among that information is the “interesting ports table”.
That table lists the port number and protocol, service name,
and state. The state is either open, filtered, closed, or
unfiltered. Open means that an application on the target
machine is listening for connections/packets on that port.
Filtered means that a firewall, filter, or other network
obstacle is blocking the port so that Nmap cannot tell whether
it is open or closed. Closed ports have no application
listening on them, though they could open up at any time. Ports
are classified as unfiltered when they are responsive to Nmap's
probes, but Nmap cannot determine whether they are open or
closed. Nmap reports the state combinations open|filtered and
closed|filtered when it cannot determine which of the two
states describe a port. The port table may also include
software version details when version detection has been
requested. When an IP protocol scan is requested (-sO), Nmap
provides information on supported IP protocols rather than
listening ports.
Those won't be affected by iptables rules for ports 80 and 443 on your RPi at all.
It is only with a blocked domain and a blocking mode that involves Pi-hole's blocking page that those rules would kick in.
The blocking page itself will work for HTTP only, so why not consider switching to Pi-hole's default NULL blocking mode? iptables for 80/443 would be completely obsolete then.
Dont forget creating debug token and post here.
Keep in mind the (default) NULL blocking mode is still preferred one.
Clients will query ad domains and they get 0.0.0.0 returned.
No errors or timeouts.