Summary: | DROP_HOSTILE IN= log message with no IN= results for green & blue | ||
---|---|---|---|
Product: | IPFire | Reporter: | Jon <jon.murphy> |
Component: | --- | Assignee: | Assigned to nobody - feel free to grab it and work on it <nobody> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | - Unknown - | ||
Priority: | - Unknown - | CC: | michael.tremer, peter.mueller |
Version: | 2 | ||
Hardware: | unspecified | ||
OS: | Unspecified | ||
Attachments: | Log |
Description
Jon
2022-04-14 18:24:28 UTC
This probably isn't a bug. It is just a packet that originated from the firewall and therefore does not have an IN= interface. This is most likely the web proxy since it is port 80. it was me! I opened a browser and entered `my-authentication-x322s[.]com` just to test. See: https://community.ipfire.org/t/location-block-vs-drop-packets-from-and-to-hostile-networks-listed-at-spamhaus-drop-etc/7434/10?u=jon So this is NOTABUG? I think it is a bug since IN=<blank>. It should be IN=green0. I am hoping Peter will chime in! Created attachment 1038 [details] Log Just found this. When I open a Safari browser and enter: `http://my-authentication-x322s.com` then IN=<blank> When I open a Safari browser and enter HTTPS (not HTTP): `https://my-authentication-x322s.com` then IN=green0 (In reply to Jon from comment #4) > I think it is a bug since IN=<blank>. > > It should be IN=green0. No, it should not. The proxy is opening a new connection which originates from the firewall itself. It might be logically tied to the connection that your browser has to the proxy, but that does not matter to the firewall. The reason why you don't see this for HTTPS is that your proxy is in transparent mode which does not handle HTTPS. |