Should I configure a firewall to allow multicast?

I'm using IP filter on a Sun workstation (IP 192.168.1.9) and see the firewall is blocking various hosts to 192.168.1.255 port 138. Note this machine is not a router, so really no machine on the network should rely on this one even being running.

Anyway, this is my ipfilter log, showing data from 192.168.1.101 (a PC) port 138 and 192.168.1.128 (another PC) going to 192.168.1.255 (this is not any machine as such).

I think there was

the following in the log from various local hosts

23/03/2009 12:58:44.000795 eri0 @0:15 b 192.168.1.101,138 -> 192.168.1.255,138 PR udp len 20 229 IN multicast 23/03/2009 13:04:16.665658 eri0 @0:15 b 192.168.1.128,138 -> 192.168.1.255,138 PR udp len 20 240 IN multicast 23/03/2009 13:14:16.667128 eri0 @0:15 b 192.168.1.128,138 -> 192.168.1.255,138 PR udp len 20 240 IN multicast 23/03/2009 13:17:28.791530 eri0 @0:15 b 192.168.1.101,138 -> 192.168.1.255,138 PR udp len 20 244 IN multicast 23/03/2009 13:18:18.926805 eri0 @0:15 b 192.168.1.128,138 -> 192.168.1.255,138 PR udp len 20 229 IN multicast 23/03/2009 13:22:43.225333 eri0 @0:15 b 192.168.1.101,138 -> 192.168.1.255,138 PR udp len 20 229 IN multicast

I tried creating some rules to allow this, but for some reason it is still being blocked.

pass out quick on eri0 proto udp from 192.168.1.9 to 192.168.1.255 pass out quick on eri0 proto udp from 192.168.1.0/24 to 192.168.1.255 port = 137 pass in quick on eri0 proto udp from 192.168.1.0/24 to 192.168.1.255 port = 137

So I'm not sure if it's best to allow these packets or stop them. If its better to allow them, which is a suitable firewall rule for ipfilter?

Reply to
Dave
Loading thread data ...

Let's have a look at the output of '/sbin/ifconfig -a' and '/sbin/route -n'. This smells like a bit of confusion on your part related to addresses used in IP.

Are 192.168.1.101 and 192.168.1.128 running Samba, or windoze? Both RFC0791 and RFC1122 were written long before "Classless Inter-Domain Routing" (CIDR) (RFC1519), but this sounds like normal _broadcast_ activity.

You're implying that /sbin/ifconfig and /sbin/route would show a local network running from 192.168.1.0 through 192.168.1.255 which would show up as a network mask of 255.255.255.0 or FFFFFF00. In that case,

192.168.1.0 would be the "network address" which in SOME operating systems can also be used as a host address, and 192.168.1.255 os the broadcast address - received by every host on the subnet. Broadcasts are normally used when the sending system doesn't know the correct address of the destination, or in packets destined for all systems. This is quite normal.

Is everything working OK? Are you simply worried that having packets sent to this "unknown" (to you) address is/maybe harmful? I don't use windoze or Samba, but understand that packets to the local broadcast address are normal for that protocol.

Old guy

Reply to
Moe Trin

I suspect it is confusion, but I know for certain there are no hosts with an address of 192.168.1.255.

# /sbin/ifconfig -a lo0: flags=2001000849 mtu

8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 mtu 1500 index 2 inet 192.168.1.9 netmask ffffff00 broadcast 192.168.1.255 ether 0:3:ba:16:e4:55

# /sbin/route -n usage: route [ -fnpqv ] [ -R ] cmd [[ - ] args ]

Not sure what you want there. -n does not appear to be supported in Solaris.

I dont know if theis is any use. The IP of the Sun on which this is run is 192.168.1.9.

# netstat -rn

Routing Table: IPv4 Destination Gateway Flags Ref Use Interface

-------------------- -------------------- ----- ----- ---------- --------- default 192.168.1.1 UG 1 409

192.168.1.0 192.168.1.9 U 1 1031 eri0 224.0.0.0 192.168.1.9 U 1 0 eri0

Yes, both are Windows PCs which use Samba shares. Samba runs on the Sun where I see these messages.

You don't surprise me. So would it be sensible for the firwall not to block it?

It would be useful if I could pass it, and so not logged it being blocked. I like to keep an eye on the blocked packets, to see if they should have been permitted, and so I need to add a rule to permit them. Hence blocking unnecessary thing is not ideal.

Somethings seem rather slow since I changed the router, and needed to change firewall rules. I have not had time to determine what is amis. It is possible it is just the internet as a whole, but I'm sligtly concerned maybe data is getting lost which would help speed up internal traffic. Not sure if that is possible or not.

As I said above, I'd like stop these messages being logged, but I can't seem to find a rule that stops it. Hence I have lines like:

23/03/2009 21:32:32.527497 eri0 @0:17 b 192.168.1.101,138 -> 192.168.1.255,138 PR udp len 20 244 IN multicast

despite having these two rules now.

pass out quick on eri0 proto udp from 192.168.1.0/24 to 192.168.1.255 port 137 138 pass in quick on eri0 proto udp from 192.168.1.0/24 to 192.168.1.255 port 137 138 keep state

Reply to
Dave

Yes but

Even says so right here - 192.168.1.255 is the broadcast address.

The -n option tells the system not to try to resolve the address to a name. No big deal, as the ifconfig provided the data needed. I haven't used Solaris in several years, hence the confusion on my part. I don't see that many Solaris posts to this group, and you _may_ have better luck over in 'comp.unix.solaris' or possibly 'comp.sys.sun.admin'.

You speak about 'multicast' - the IP address range of 224.0.0.0 to

239.255.255.255 (network mask 240.0.0.0 or f0000000 or /4) is where multicast lives. This service (RFC1301, RFC1458, RFC2365) is directing packets to multiple clients who have _requested_ to receive them. One example of this might be Internet Radio. This differs from 'broadcast' which sends packets to the network broadcast address (192.168.1.255 in this case) for everyone. Another difference about broadcast is that the packets _tend_ to be small.

OK - that's what is causing this traffic. No, you don't want to filter this, and you _probably can't. Windoze networking uses the broadcast address for short but critical messages - advertising the existence of shares, locating a domain controller, and the like.

Correct. Obviously the entire network address range would be blocked at the perimeter (RFC2827 and/or RFC3704), but that's an entirely different problem.

My guess is that you've got some other "blanket" rule that is causing the logging.

Not enough details. "Slow" is usually used to describe a situation where the initiation of a connection is slow - using telnet as an example, the client program starts, but the login prompt takes up to a minute to appear. Once you log in, everything runs at normal speed. That particular problem is a name resolution problem - the _server_ is attempting to look up the name of the _client_ for the logs. A common solution is to fix the DNS, _OR_ add all of the client hostname/IP data to the /etc/hosts file on the server.

The method to troubleshoot that problem is to use a packet sniffer to see what traffic is going where. The classic tool is 'tcpdump', but I believe 'Snoop' or 'GreedyDog' are more common for Solaris. There are at least twenty such tools, not all of which run/compile on all O/S.

Old guy

Reply to
Moe Trin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.