1° issue: 192.168.3.16 is a smartphone connected to 192.168.3.2 that is a wireless access point connected to ipfire port BLUE ip 192.168.3.1
cannot gain access to mail server provider (example google, yahoo…) on first attempt, firewall log:
FORWARDFW blue0 TCP 192.168.3.16 → IP of mail provider tcp 44216 → 993 imaps 3° attempt OK
DROP_NEWNOTSYN blue0 TCP 192.168.3.16 → IP of mail provider tcp 44158 → 993 imaps 2° attempt
DROP_NEWNOTSYN blue0 TCP 192.168.3.16 → IP of mail provider tcp 44158 → 993 imaps 1° attempt
2° problem (and this happens every morning! Yesterday I solved rebooting the modem on RED, this morning instead I simply booted up my pc on GREEN and magically all wireless devices gained internet access again), firewall log:
DROP_NEWNOTSYN blue0 TCP 192.168.3.16 → google 47890 → 443 HTTPS
DROP_NEWNOTSYN blue0 TCP 192.168.3.7 (another wifi devices) → 192.168.3.1 (port blue on ipfire where is connected the wifi access point) port 46929 → 800 (MDBS_DAEMON) and this entry occurs many many times!!
Yes I have web proxy activated on blue and green, both not in invisible mode.
All this happens only after the upgrade to release 157.
I have no rules blue to green and viceversa but everything worked correctly before update
Second: Perhaps I (we?) should clarify DROP_NEWNOTSYN a bit to avoid confusions. This means IPFire observes a
TCP connection it has not observed so far, otherwise there would be an entry in the connection tracking table for
it. New TCP connections start with a packet having a SYN flag, but if they don’t, they are considered invalid or
being some type of scanning.
In the past, some network software written by completely braindead companies (this included some components of
earlier Windows versions as well, if I remember that correctly) emitted TCP connections without a SYN flag at first.
These days, however, such connections are only rarely processed; the vast majority of NEWNOTSYN connections
come from port scans. They also appear if IPFire was rebooted - hence its connection tracking table has been cleared -,
but clients behind it were not. So, their connections time out.
DROP_NEWNOTSYN blue0 TCP 192.168.3.16 → google 47890 → 443 HTTPS
DROP_NEWNOTSYN blue0 TCP 192.168.3.7 (another wifi devices) → 192.168.3.1 (port blue on ipfire where is connected the wifi access point) port 46929 → 800 (MDBS_DAEMON) and this entry occurs many many times!!
That sounds like a crappy wifi device indeed…
All this happens only after the upgrade to release 157.
Do you observe this behaviour after having rebooted all active network devices behind IPFire?
I’ll wait tomorrow morning. In the meantime I set web proxy authentication from “identd” to “none” as many tutorials suggest. Set firewall rule Blue to Green and reduced the lease times in the DHCP server.
After that I’ll check all logs.
Wireless access point not rebooted after Ip fire update. Minutes ago for precaution I rebooted it manually…could be an extra help.
reguarding the " DROP_NEWNOTSYN" explanation for me was clear the meaning, anyway sounds strange, cause I simply took my smartphone, set wifi to ON, device correctly connected to access point on 192.168.3.2 then tried to open Google as Play store or anyone else needs internet and no response, then firewall logs say blocking traffic with no reason. Same thing asking to my Alexa devices something…they were not able to access internet…but they are constantly connected to wifi access point and, as we all know, these devices call home every second.
same thing this morning but this time modem had some disconnections caused by ISP. Worked on windows wireless devices, not for android devices. Example, tried using whatsapp results in first attempt DROP_NEWNOTSYN from my phone to whatsapp server. Second attempt FORWARDFW and worked correctly. But must work out of the box in the first attempt cause connection is started from LAN that is set to ACCEPT
Every device is set with proxy pointing to 192.168.3.1 and port 800 for web proxy. I think web proxy is not working correctly after update.
Proxy is working in my core 157 installation, both on green and blue(hostapd).
Therefore I suppose, the problem is located in your configuration.
Do you have some ‘special’ firewall rules?
How is your (separate) AP configured?
I found web proxy is not working cause setting an url in blacklist will not be blocked…
I have this firewall rules:
from GREEN standard network to RED standard network ACCEPT
from BLUE standard network to GREEN standard network ACCEPT
from BLUE standard network to RED standard network ACCEPT
from RED standard network to GREEN standard network DROP
from RED standard network to BLUE standard network DROP
and these the INCOMING FIREWALL ACCESS RULES:
from GREEN standard network to FIREWALL GREEN 192.168.2.1 service DNS + DESTINATION NAT FIREWALL INTERFACE AUTOMATIC (this rule to prevent DNS hijacking as IPFire wiki)
the same for BLUE anti DNS hijacking
from GREEN standard network to FIREWALL GREEN 192.168.2.1 ACCEPT
from BLUE standard network to FIREWALL BLUE 192.168.3.1 ACCEPT
Pardon my interjection but is this related to the proxy issue that started back in 155 that many of us have had problems with?
After any reboot since updating to 155 and later the web proxy must be restarted or cache cleared in order to allow url’s through browsers set to the proxy port. It was reported to bugzilla but it is still an issue now for two versions. Oddly it doesn’t stop other services as i can still remote into the pc’s.
The proxy acts as if its off, which it tends to be after a firewall restart with this bug, and we all have to manually force it to start via command line or on the gui. Whats odd is that just a “clear cache” on the gui fixes it too.
I also have 2 firewalls that do it even though they dont reboot, ever day they have to be refreshed to restart the proxy yet the logs show no event or restart. I moved it to a non default port as some said to do and yet no change.
