BTW, in your earlier posts, I noticed this:

FW_ALLOW_INCOMING_HIGHPORTS_TCP="netbios-ns microsoft-ds"

FW_ALLOW_INCOMING_HIGHPORTS_UDP="netbios-ns microsoft-ds"

Leave these blank, if you open the single port using yast! This is a security hole that should be closed if you use this machine as a firewall between you and the internet.

Well, I'm back. The destination port changes on a reboot so the YAST method is not a permanent fix.

The most secure way is to accept all UDP requests from port 137 of any computer to any DPT over port 1024. I can show you how to do it, but the easiest way is to just do the manual /etc/sysconfig/SuSEfirewall edit way of FW_ALLOW_INCOMING_HIGHPORTS_UDP="YES".

Well, today isn't either one of our days. Apparently in 9.3 the FW_ALLOW_INCOMING_HIGHPORTS_UDP= has a bug that prevents it from being activated. A fix should be out soon via YOU.

The only other thing I can think of is go back to Yast to the UDP Ports section and put in "1025:65535" to open up the full range. It will complain that it's not a valid range but just accept it and go on your way.

I guess my point of "it has it's flaws" are a little more true than I expected.

ghigh, thanks for the quick reply. I'm not at my computer right now, but I'll try this out as soon as possible. Your help is greatly appreciated.

Okay, last reply. I promise!

What is supposed to happen (and exactly what you need) when you use the FW_ALLOW_INCOMING_HIGHPORTS_UDP= is you are supposed to put in either YES, NO, or the source port number. Once SuSE has a fix for this, go back and put in '137' in and it will take any UDP packet from a source port of 137 and pass it on to any port above 1024.

This would will ultimately be the most secure fix, but alas, it's not working currently. The ugly "hack" will have to work for now or as has been mentioned, you can always just use something else. I actually like Shorewall for my non-SuSE servers, but it can be pretty uninuitive as well.

Well ghight you have certainly demonstrated that you know your stuff! My hat is off to you!!!

I don't know why you thought I was attacking you personally, but I assure you that I wasn't. I'm a 92 year-old guy who can't remember what day of the week it is. Everything I read yesterday and today will be forgotten by next week. If you want to think of that as laziness, that's your right, but I think of it as knowing my own limitations and trying to live within them.

I saw a couple of things in apachedude's config file that troubled me and I wonder if you'd comment on them for his benefit.

FW_SERVICES_EXT_TCP="137 138 139 445 microsoft-ds netbios-dgm netbios-ns netbios-ssn"

He's defined these ports twice, by both port # and alias. Is that a problem?
And does he really need 139 & 445?


FW_SERVICES_EXT_UDP="137 138 139 445 netbios-ns"

Same questions as previous.

FW_ALLOW_FW_BROADCAST_EXT="137 138 139 445"

Does he need 139 & 445?

FW_ALLOW_FW_BROADCAST_INT="137 138 139 445"

Does he really need any of these?

FW_IGNORE_FW_BROADCAST_EXT="no"

Won't this cause a bunch of unnecessary logging?

Best regards...

Edit: BTW, FWIW I looked at my own machine and found that DPT is 1025 today but it was 1026 yesterday and looking back through the log I've seen at least three or four other similar values so it looks like this is a moving target...

I believe I also have a "changing" DPT. Unfortunate, because I think the firewall was working properly before it changed. ghight, are you aware of a fix for this, or do you suggest I try something more "dumbed down" like GuardDog?

I think he already covered that. Look back in this thread to posts #18 and #20 which offer a circumvention until Suse releases a needed patch.

Adding the port range of "1025:65535" in the UDP ports box of the Advanced section should be a work around. According to the author of the firewall, a bug report has been filed and has already been fixed. It will take a week or so for the fixed version to be loaded on the mirrors. Keep your fingers crossed.

You are always free to use whatever you want.

BTW, I do feel that this is an issue that should be taken care of automatically when selecting Samba in the allowed sevices box, and I will try to bring it up with the SuSE folks to see if this can be added in to the next version and if not, why.

No luck. I haven't tried your latest suggestion, ghight, but for some random reason, I now can't see my workgroup even with the firewall turned off. Sometimes I see the workgroup of my neighbor, even though I have not changed my Samba client settings.

Odd. Maybe it'll go back to normal in a few days.

Your neighbor as in your next door neighbor? Are you running a wireless lan? If so, sounds like you may have other issues to get hammered out before we wrap this up.

No, I'm connected over a router with a CAT5 cable, which I find very strange. Both my roommates are also connected to that same router, and I have absolutely no idea what is going on.

Hmm, well disable the firewall and test everything out again. The firewall can do forwarding, but if anything, you'd be able to see both workgroups, not just someone elses. I'd say reboot and retry. I'm positive once you get all the previous changes out of your config file, then put in SAMBA in the allowed services box with the ports listed above in the Advanced/UDP Ports box, it will work. If not maybe your other router is somehow blocking packets. Just a guess.

What is going on with your router I guess could be another thread, although I'd politely inquire with your roomies if they've been messing with it.

ghight's config of 1025:65535 resolved my connection problem completely.

I noticed your FW_DEV_EXT= appears to show three external connection devices. Maybe that needs another look...

My friend has no idea what's going on either. I'm not even sure how I could be connected to my neighbor. (I presume it's my neighbor, because as illogical as it sounds, it makes more sense than me being connected to some random guy halfway around the world.)