| |
| |
| |
|
Page: 1 2 3
Comments:
<0> right, that's what I was implying
<1> You imply well. Let me think about the redundant part...
<0> onw_filter_backbonetraffic --> you really shouldn't filter in the nat table
<0> um, hold on - wrong paste
<0> -A PREROUTING -p udp -m udp --dport 137:139 -j DROP
<0> In this case, it's probably not really an issue, but the proper place to filter is in the filter table
<1> Only the second rule was redundant.
<2> or I think you can use the raw table if you really want to filter in PREROUTING
<1> I haven't used the "raw" table...
<0> onweald_tim: yeah, you're correct about the second rule - the first one is okay
<1> danieldg: So it is okay (good form) to use raw for filtering?
<1> I just wanted to catch it as early as possible.
<2> I'm not certain about "good form" - it doesn't have any of the problems that NAT has though
<1> robw810 is right... I shouldn't filter in prerouting.
<1> s/prerouting/nat/
<2> yeah, the only filtering I do in raw is of misc broadcast noise on this network
<1> What problems are there with nat? I noticed that I didn't get some packets flowing through it once they had been SNAT'd
<1> I ***ume that is the problem?
<0> I've never used the raw table, so I am likewise uncertain about the specifics there - I've always just filtered that type of thing with a DROP rule before the LOG rule
<0> (***uming I'm logging anything to begin with)
<2> a connection will only go through the nat table once
<0> onweald_tim: yeah, the nat table will only see the first packet of a new connection; everything else is caught by conntrack
<1> Well I just learned something new for the day.
<1> I iz edumacated! :-)
<2> actually, I don't use DROP in the raw table, I use NOTRACK and then drop UNTRACKED later
Return to
#iptables
or
Go to some related
logs:
KDE compiz super*key
-malignment-traps gcc4
#php
compiz Speicherzugriffsfehler
vncserver troubleshot
sh: -c: line 0: unexpected EOF while looking for matching `'' + centos
phosphor screensaver fc5
kungkfu
ls -l /dev/ttyS00
#linux
|
|