I have a networking question that is only partly related to IPFire and I’d be grateful if someone could provide an answer please.
I’m getting entries in the IPFire firewall logs every 30 seconds from a device (iPhone) with static address that is in a different subnet to the IPFire device. This is the configuration…
Router is in DNAT. (IPFire Main page shows Internet IP as 192.168.1.100 and Gateway as 192.168.1.1. Network LAN IP is 192.168.10.1/24).
IPFire Firewall Policy is DROP (forward, outgoing, input). Default behaviour is FORWARD (Blocked), OUTGOING (Allowed).
This all works fine.
However, entries in the IFPire Firewall Log show Source IP and Destination IP as being in the 192.168.1.nn range. The Source IP (iPhone) is 192.168.1.40 and destination IP is 192.168.1.255. The source and destination ports are sometimes port 137 (Netbios) and other times port 57621 (? don’t know what this port represents). The entries occur every 30 seconds.
Any ideas on why source and destination traffic from a different subnet is occurring on the IPFire subnet please?
The term ‘DNAT’ can be interpreted in several ways. Commonly, with a setup like you’ve described, IPFire would be assigned to the DMZ on your modem/router. This configuration forwards all incoming internet traffic to IPFire’s IP (e.g., 192.168.1.100), and the modem/router (e.g., 192.168.1.1) is set as the default gateway for the IPFire’s red interface. This setup broadly forwards traffic to IPFire, unlike traditional DNAT, which is typically configured for specified ports.
Can you verify that your configuration aligns with the one I’ve outlined?
Regarding the routing anomaly you’re observing, it involves an iPhone with a static IP within the 192.168.1.0/24 subnet, creating log entries on the IPFire system on a different subnet (192.168.10.0/24). Notably, traffic from the iPhone’s IP (192.168.1.40) targets the subnet broadcast address (192.168.1.255) over ports 137 (NetBIOS) and 57621 (undetermined usage).
The primary concern here is that NetBIOS traffic, typically non-routable and limited to the local broadcast domain for name resolution and service advertisement, is being logged by IPFire, indicating that the router may be erroneously forwarding subnet broadcast traffic to IPFire. This behavior is an anomaly as routers should not forward broadcast traffic between different subnets.
The secondary issue pertains to port 57621. Since it’s not associated with any standard services, it could relate to a specific application or dynamic port usage on the iPhone. Again, it appears the router is indiscriminately routing this traffic to IPFire, contrary to typical network practices.
From my understanding the WAN ip of IPFire is in the same subnet as phone and Modem/ router.
So broadcast traffic will show up.
And ports 57621 looks like may be Spotify.
Thanks to you and @cfusco for the quick response. I’m not a network person and your replies help me think it through a bit more.
I was pretty sure its Spotify doing broadcast/multicast. Thanks for the info re port 57621. To confirm I could delete the app and reinstall but…
You are correct that the IPfire device is in the same subnet as the iPhone so gets the broadcast traffic. I didn’t realise but its obvious now you have pointed it out
I’ll search for a way to stop Spotify doing the broadcast every 30 seconds. In the mean time I’ll create a rule so the logs aren’t filled with these hits.
Thanks again, much appreciated.
Glad you got this figured out. Here is a bit more info that might be helpful.
Your IPFire is seeing the traffic because the Red/WAN interface is on the same network/segment, as @hvacguy mentioned.
The 255 in the addresses indicates the traffic is a broadcast directed at all 254 addresses in the subnet 192.168.1.x/24, including 192.168.1.100 IPFire-Red.
The iPhone in the DMZ is probably broadcasting to find Spotify and Microsoft peers on the local network. IPFire will block those broadcasts and other traffic from the iPhone.
Your setup looks like a typical two router with DMZ topology like the first diagram below. (The second diagram is another variation with a single firewall with DMZ).
Devices in the DMZ can access the internet and other devices in the DMZ subnet by default. Also, connections to the DMZ devices can be initiated from Green devices and will be replied to. However, devices in the DMZ cannot initiate a connection to the Firewall or devices on the Green LAN (per default Firewall DROP Policy). You can override the default behaviour by creating port forwarding rules in the WUI if needed.
For comparison, I have a similar setup in a test environment. A firewall log excerpt from that setup shows DHCP and NetBIOS(MS Name resolution) broadcast traffic from a Windows PC in the DMZ being DROPPED/BLOCKED at the Red interface.
As long as your IPFire Firewall logs show the iPhone traffic as DROP_INPUT on the Red interface this is normal expected behavior.
You won’t be able to reduce or turn off the DROP_INPUT logging with a Rule in the WUI. It is managed by a toggle ‘Log dropped input packets’ under Firewall->Firewall Options.
Thanks @wiztech for your reply. The second scenario is what I am working towards. There are a number of reasons why I haven’t got there yet.
I don’t want to digress into another topic since my original question has been answered. However… your comment about not being able to ‘turn off’ logging with a rule in the WUI raises a situation I looked at a while back. I didn’t follow through with it but it does seem that the logging option in the Firewall Options overrides ‘Log’ when set on a rule. I guess that is correct for all firewall rules?
your comment about not being able to ‘turn off’ logging with a rule in the WUI raises a situation I looked at a while back. I didn’t follow through with it but it does seem that the logging option in the Firewall Options overrides ‘Log’ when set on a rule. I guess that is correct for all firewall rules?