All of lore.kernel.org
 help / color / mirror / Atom feed
From: ph4ke <deff@sadomain.co.za>
To: lartc@vger.kernel.org
Subject: [LARTC] Finally got FWMARK to work
Date: Thu, 06 Nov 2003 08:29:54 +0000	[thread overview]
Message-ID: <marc-lartc-106810739400469@msgid-missing> (raw)


Hi List, 

Only signed up recently and posted the problem that we had with FWMARK. 

Got it solved, so if anyone has the same problem, maybe this could help : 

The problem with the (redhat) 2.4.20 kernel was that when doing ethernet 
bridging, packets seemed to bypass iptables rules, thus no marking occurs. 

Apparently there is a patch available to allow firewalling on the bridge but I didn't bother to 
use it. Funny thing is that the kernel that comes with RH 7.3 actually does let bridged packets 
be filtered by iptables . 

We finally opted for the 2.6.0-test1 kernel and everything is working fine now. Iptables 
is marking the bridged packets, and tc is queuing them as the filters dictate.  

Just thought I'd share that. 

For limiting the ftp-outgoing involved a little of iptables sorcery. 
See, the problem is that we want to limit outgoing ftp to a particular ip range, but the 
ftp server actually sits on a webserver as well. 

So i tried these rules to mark the packets, looks like its working fine. If there is a better way 
to accomplish this, please let me know, cause I'm sure this isn't the best way : 

target       prot opt  source                    destination
MARK       tcp  --  100.200.100.10        xxx.xxx.xxx.xxx     state RELATED,ESTABLISHED MARK set 0x1 ## ftp marking rule
MARK       tcp  --  anywhere             anywhere               tcp spt:http MARK set 0xa	
MARK       udp  --  anywhere             anywhere              udp spt:http MARK set 0xa

0x1 goes to the htb class where we limit the traffic 
0xa just goes to an htb class with a sfq qdisc attached to it 
Everthing else also goes to the sfq by default 

So this works fine. FTP downloads from the limited range are limited nicely, and uploads of "new" files 
from that range is fast, just like it should be. 

The only thing is that when you upload from the range and overwrite files on the ftp server, it gets limited 
just like if you where doing a download. This is extremely odd to me and if anyone has any 
ideas of why this might happen please give me a shout. 


Regards, 
Cilliè








_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

                 reply	other threads:[~2003-11-06  8:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-106810739400469@msgid-missing \
    --to=deff@sadomain.co.za \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.