I have a port forwarding to HTTPS that’s not working for some IP addresses – in the log I get DROP_INPUT on at least one address. It’s not in any specific list, and it’s obviously not indicated by a notice about a list etc. I have location blocking on and also a couple of lists – lists are indicated when traffic is dropped, but perhaps location blocking is just indicated by DROP_INPUT? Or is there another way of seeing why traffic was dropped?
I’m trying to understand what you wrote.
So you have forwarding an server, but other IP addresses in the network can’t access the public URL?
Then you need to add the public URL in Hosts so other clients are directed by the DNS inside IPFire.
- I forward port 443 to an internal HTTPS server (on Orange).
- It works for everyone on the internet…
- …except one (or possibly two, not sure yet) IPs. These are dropped by the FW, with a DROP_INPUT log entry.
- The IP(s) are not in any blocklist. They are not manually blocked. They are not in a country blocked by Location Block (all blocks are in fact turned off).
A log entry might look like this:
/var/log/messages:123810:May 14 16:40:10 MGfire kernel: DROP_INPUT IN=red0 OUT= MAC=01:02:03:81:78:01:a4:55:29:40:ac:a6:08:00 SRC=6.6.6.6 DST=9.9.9.9 LEN=64 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=59972 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
…where the placeholder 6.6.6.6 is the offending remote IP (the one that gets blocked) and 9.9.9.9 naturally is my placeholder IP.
Well, I updated everything (it was REALLY old) so we’ll see if that solved the problem. I find it super strange though.
Could we see it?
No. It would be indicated by LOCATIONBLOCK
However I believe you won’t see that chain in the logs as Location Blocking was put in place to minimise the amount of log messages on systems with extremely cheap flash storage so Location Blocking is not logged.