Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: OpenMacNews <fwbuilder.20.openmacnews@sp...> - 2004-08-30 20:03:53
|
hi,
i've just installed a SAMBA server on my LAN, for use/broadcast ONLY inside the LAN.
despite all other internal traffic flowing along nicely, i'm seeing related port 138 traffice caught by my Global Catch-all rule:
Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] IN=br0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP SPT=138 DPT=138 LEN=214
where 10.0.0.2 is the SAMBA box, and 10.0.0.1 is the Firewall/Gateway
as a debugging step, i setup an Internal Intfc rule:
Src: LAN
Dst: LAN
Direction: Both
Action: Accept, Log
which does what i think it should be doing, i.e., ALLOW this traffic:
Aug 30 12:54:05 linksys kernel: [br0(0) ACCEPT] IN=br0 OUT=br0 SRC=10.0.0.2 DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP SPT=138 DPT=138 LEN=214
so, question is, why is the LAN-to-LAN traffic subsequently falling through to the GlobalCatchAll rule? the MAC address and no "OUT=" makes be suspect the FW object needs to involved ... but what rule specifically?
richard
|
|
From: Vadim Kurland /r/ <vadim@vk...> - 2004-08-30 20:57:09
|
On Aug 30, 2004, at 1:03 PM, OpenMacNews wrote: > hi, > > i've just installed a SAMBA server on my LAN, for use/broadcast ONLY > inside the LAN. > > despite all other internal traffic flowing along nicely, i'm seeing > related port 138 traffice caught by my Global Catch-all rule: > > > Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] IN=br0 > OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 > DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP > SPT=138 DPT=138 LEN=214 > these are broadcast packets, that's why your firewall sees them. There is no harm in blocking them on the firewall; it would not be able, or need to, use them anyway. --vk > where 10.0.0.2 is the SAMBA box, and 10.0.0.1 is the Firewall/Gateway > > as a debugging step, i setup an Internal Intfc rule: > > Src: LAN > Dst: LAN > Direction: Both > Action: Accept, Log > > which does what i think it should be doing, i.e., ALLOW this traffic: > > Aug 30 12:54:05 linksys kernel: [br0(0) ACCEPT] IN=br0 OUT=br0 > SRC=10.0.0.2 DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 > PROTO=UDP SPT=138 DPT=138 LEN=214 > > so, question is, why is the LAN-to-LAN traffic subsequently falling > through to the GlobalCatchAll rule? the MAC address and no "OUT=" > makes be suspect the FW object needs to involved ... but what rule > specifically? > > richard > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Fwbuilder-discussion mailing list > Fwbuilder-discussion@... > https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
|
From: OpenMacNews <fwbuilder.20.openmacnews@sp...> - 2004-08-30 21:06:43
|
>> hi, >> >> i've just installed a SAMBA server on my LAN, for use/broadcast ONLY >> inside the LAN. >> >> despite all other internal traffic flowing along nicely, i'm seeing >> related port 138 traffice caught by my Global Catch-all rule: >> >> >> Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] IN=br0 >> OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 >> DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP >> SPT=138 DPT=138 LEN=214 >> > > these are broadcast packets, that's why your firewall sees them. There is no harm in blocking them on the firewall; it would not be able, or need to, use them anyway. understood. but isn't a BROADCAST considered lan-to-lan traffic? and therefore should not be 'generically' blocked under any circumstance? AFAIK, there's no specific rule *prohibiting* this traffic ... at the very least, which specific rule needs to be enable to ensure that these packets -- even tho caught -- are not logged by the global catch-all? richardf |
|
From: Vadim Kurland /r/ <vadim@vk...> - 2004-08-30 21:16:13
|
On Aug 30, 2004, at 2:06 PM, OpenMacNews wrote: >>> hi, >>> >>> i've just installed a SAMBA server on my LAN, for use/broadcast ONLY >>> inside the LAN. >>> >>> despite all other internal traffic flowing along nicely, i'm seeing >>> related port 138 traffice caught by my Global Catch-all rule: >>> >>> >>> Aug 30 12:54:05 linksys kernel: [Catch: global(20) DENY] >>> IN=br0 >>> OUT= MAC=ff:ff:ff:ff:ff:ff:00:00:46:d3:e2:1b:82:00 SRC=10.0.0.2 >>> DST=10.0.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=35443 PROTO=UDP >>> SPT=138 DPT=138 LEN=214 >>> >> >> these are broadcast packets, that's why your firewall sees them. >> There is no harm in blocking them on the firewall; it would not be >> able, or need to, use them anyway. > > > understood. > > but isn't a BROADCAST considered lan-to-lan traffic? and therefore > should not be 'generically' blocked under any circumstance? AFAIK, > there's no specific rule *prohibiting* this traffic ... > is there specific rule permitting it ? If not, then catch all rule prohibits it. > at the very least, which specific rule needs to be enable to ensure > that these packets -- even tho caught -- are not logged by the global > catch-all? > method 1: a rule somewhere above the catch-all one, with action DROP and no logging, with source and destination "any" and collection of some service objects in service. These objects should be all services you do not care about that generate broadcast packets, such as all this Microsoft stuff, DHCP, may be something else. If you put this rule in the global policy, it will drop without logging these on the outside as well Obviously you should not block DHCP in a rule like this if you use your firewall as DHCP server for the LAN. Use your judgment. method 2: a rule with action ACCEPT and no logging, with source and destination 10.0.0.0/24 and service 'any'. This will permit all sorts of things from internal LAN to broadcast as well as to the firewall itself. If you trust your LAN, it is not a problem that you permit everything from it to the firewall. This rule won't filter junk on the outside. I believe you either used to have or have now a rule per #2. --vk |