[LARTC] Re[4]: local address routeable?

2003-07-17 Thread Christian Stuellenberg
> "Christian" == Christian Stuellenberg <[EMAIL PROTECTED]> writes:
> "Julian" == Julian Anastasov <[EMAIL PROTECTED]> writes:
Hello,

Christian> If traffic from zone MASQ is addressed to one of the
Christian> external internet addresses of one of the zone GOOD or
Christian> DMZ, then it will currently get routed directly at
Christian> HOST.  It is intended, that this direct routing is not
Christian> done, but instead ALL traffic from zone MASQ becomes
Christian> masqueraded out over the dynamic PPP connection to the
Christian> internet, comes back over the CISCO line to HOST, then
Christian> gets routed to the extern destination IP (in zone GOOD
Christian> or DMZ) and when the reply from there comes back again
Christian> to HOST, it should get routed over the CISCO internet
Christian> connection and then back over the dynamic PPP
Christian> connection, demasqueraded, and at last delivered to the
Christian> original source in zone MASQ.

Christian> This works up to the point, where the reply comes back
Christian> to HOST.  Now I'm not able to tell HOST, that this
Christian> reply should again routed out to the internet over the
Christian> CISCO line and only demasqueraded if it comes in over
Christian> the PPP connection (btw.  the demasquerading does also
Christian> not occur if the reply gets not routed; I assume, this
Christian> is because the masquerding tables are waiting for a
Christian> packet that comes in over the PPP connection and not on
Christian> IF0 or IF1).

Julian> I think, I understand the setup. I'm still wondering
Julian> what is the end goal. I can only speculate:

Julian> Assumption 1. Hosts from GOOD want to see client from
Julian> DynIP, not from a.b.c.62. The solution: use SNAT with
Julian> saddr=DynIP when talking to GOOD because the default
Julian> masquerade action is to use a.b.c.62 which is recommended
Julian> from the routing. I assume GOOD and DMZ do not care how
Julian> the packet with saddr=DynIP appeared as long as it looks
Julian> as expected?

Julian> 2. For some reason (even by introducing security problems)
Julian> you want packets with saddr=DynIP to walk the external
Julian> path and to reach GOOD. Is it needed? Is there a problem
Julian> with the above solution in #1?

I really want the long path, so that a client in zone MASQ can test,
whether both uplinks to the internet work correctly.  Not only to test
the links, but also to provide a way, that a client in zone MASQ looks
like any other (actually masqueraded) client in the world.  We
would'nt achieve that, if the routing from a client in zone MASQ takes
directly place on HOST.

Regards,
Christian

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] OUTPUT chain marking after or before routing?

2003-07-17 Thread Catalin Borcea
- Original Message -
From: "Martin A. Brown" <[EMAIL PROTECTED]>
To: "Chijioke Kalu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2003 6:55 PM
Subject: Re: [LARTC] OUTPUT chain marking after or before routing?


> Catalin,
>
> >When I try to connect to a smtp port somewhere in the Internet, tcpdump
show
> >me that these packets go to the eth2 interface (the main table default
> >route). I don't know where is my mistake but it seems that the marking in
> >the OUTPUT chain occurs AFTER and not BEFORE routing. Is this a correct
> >behaviour? How can I solve my problem? Please help!
>
> According to my reading of the KPTD (and my understanding), packets
> generated on the local machine have already been routed by the time the
> OUTPUT chain is traversed.  See:
>
>   http://www.docum.org/stef.coene/qos/kptd/
>

I'm very confused now. Look what is written in the iptables man page:

#
 mangle This  table  is used for specialized packet alteration.  It has two
built-in
  chains: PREROUTING (for altering incoming packets before
routing) and OUTPUT
  (for altering locally-generated packets before routing).
##

So how it is? OUTPUT marks packets AFTER or BEFORE routing?


> I see two potential approaches to this problem:
>
>   - invert your logic; main routing table uses ppp0 gateway IP as default
> gateway, mark all traffic passing through your router box, and use
> "ip rule add fwmark $MARK table $INTERNET" with another routing
> table for the Internet-bound traffic.

This approach is harder for me because this is a working gateway and I don't
wan't to disturb the users with my tests. But, it is a very good idea and
maybe I will try it.

>
>   - send all locally generated traffic via ppp0; "ip rule add iif lo
> table smtp" and watch all traffic generated on the local machine leave
> via ppp0.  You'll want to add the locally connected networks to table
> smtp.

I also tried that and it works. But I don't want to send all locally
generated traffic to ppp0. In fact I want only the smtp traffic on ppp0. The
Web traffic (including Squid generated, which is locally generated) must go
to eth2.

Thank you for your reply,

- catalin -


___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] Re: compile tcng-97 on RH9 kernel 2.4.21 (final release)

2003-07-17 Thread Dwi Cahyo
Hi, All
It's OK, sure tcng-9f cannot be compiled on RedHat 9, you must down grade
your sed, i down grade with sed-3.02-13.i386.rpm from RedHat-8.0 for i386
package, and it compiles OK


Regard,

.:: Cahyo ::.

- Original Message -
From: "Dwi Cahyo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 18, 2003 11:12 AM
Subject: compile tcng-97 on RH9 kernel 2.4.21 (final release)


: Hi, I have redhat9 with kernel with 2.4.21 (final release)
: info CHANGES
:   a.. updated kernel version example in tcng/README from 2.4.20 to 2.4.21
:   b.. setup.klib is now compatible with 2.4.21 (final release) (by Dimitry
: Ketov)
:   c.. fixed setup.klib compatibility with old kernels, like 2.4.3
: But i still seems the error with early version tcng from action "make"
: 
: ./setup.klib
: sed: -e expression #1, char 61: Invalid range end
: make[1]: *** [klib/.ready] Error 1
: make[1]: Leaving directory `/usr/local/src/tcng/tcsim'
: make: *** [all] Error 1
: 
: anybody help me, please
:
: Regard,
:
: .:: Cahyo ::.
:
:

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] compile tcng-97 on RH9 kernel 2.4.21 (final release)

2003-07-17 Thread Dwi Cahyo
Hi, I have redhat9 with kernel with 2.4.21 (final release)
info CHANGES
  a.. updated kernel version example in tcng/README from 2.4.20 to 2.4.21
  b.. setup.klib is now compatible with 2.4.21 (final release) (by Dimitry
Ketov)
  c.. fixed setup.klib compatibility with old kernels, like 2.4.3
But i still seems the error with early version tcng from action "make"

./setup.klib
sed: -e expression #1, char 61: Invalid range end
make[1]: *** [klib/.ready] Error 1
make[1]: Leaving directory `/usr/local/src/tcng/tcsim'
make: *** [all] Error 1

anybody help me, please

Regard,

.:: Cahyo ::.


___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] HTB + BRIDGEQUESTION!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!HELP!!!!!!!!!!!!

2003-07-17 Thread Trevor Warren
Hello,

 Change the ceil parameter to suit the maximum value of bandwidth on
that link. Check and get back to us.

Trevor


On Fri, 2003-07-18 at 06:28, tanxuey wrote:
> Hi everybody!
>  
> I am very glad to get htb test information from www.docum.org for the
> htb performance.
>  
> Today, I setup a bridge using brctl. my setup as following:
>  
> 192.168.2.26 |  | |
>  |- | HTB+BR box  | 192.168.2.18
>  |   eth0   | | eth1
> 192.168.2.29 |  | |
>  
>  
> I want to limit the traffics when i download data from 192.168.2.18 to
> 26 or 29.
> My script as following:
>  
> tc qdisc add dev eth0 root handle 1: htb default 10
>  
> tc class add dev eth0 parent 1:0 classid 1:1 htb rate 10Mbit
> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1Mbit ceil
> 10Mbit prio 1
> tc class add dev eth0 parent 1:1 classid 1:11 htb rate 7Mbit ceil
> 10Mbit prio 2
> tc class add dev eth0 parent 1:1 classid 1:12 htb rate 2Mbit ceil
> 10Mbit prio 3
>  
> tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst
> 192.168.2.26/32 flowid 1:11
> tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst
> 192.168.2.29/32 flowid 1:12
>  
>  26 download from 18,26 can get 900kbytes/s, but 26 and 29 download
> simultaneously, 26 get 400kbytes/s while 29 get 500kbytes/s .
>  
> i do not know why
>  
> any idea any sugestion ! please tell me,  I really appreciate your
> help!!!
-- 
( >-LINUX, It's all about CHOICE  -< )
/~\__[EMAIL PROTECTED]   __   /~\
|  \) /  Pre Sales Consultant - Red Hat \ (/ |
|_|_  \9820349221(M) | 22881326(O)  / _|_|
   \___/

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] HTB+BRIDGE QUESTION !!!

2003-07-17 Thread tanxuey





Hi everybody! 
 
Today, I setup a bridge using brctl. my setup as 
following:
 
192.168.2.26 |  
| 
|
 |- | 
HTB+BR box  | 192.168.2.18
 |    
   eth0 
  | 
| eth1
    192.168.2.29 
|  
| 
|
 
 
I want to limit the traffics when i download data from 
192.168.2.18 to 26 or 29.
My script as following:
 
tc qdisc add dev eth0 root handle 1: htb default 
10
 
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 
10Mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1Mbit ceil 10Mbit prio 1
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 7Mbit ceil 10Mbit prio 2

tc class add dev eth0 parent 1:1 classid 1:12 htb rate 2Mbit ceil 10Mbit prio 3
 
tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst 
192.168.2.26/32 flowid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst 
192.168.2.29/32 flowid 1:12
 
 26 download from 18,26 can get 
900kbytes/s. if 26 and 29 download simultaneously, 26 get 
400kbytes/s while 29 get 
500kbytes/s .
 
I had thought 26 gets 875kbytes/s and 29 gets 250kbytes/s.
 
i do not know why
 
any idea any sugestion ! please tell me,  I really appreciate your 
help!!!
 
I have two email accounts. one is [EMAIL PROTECTED] which has added to your 
mail list the other is [EMAIL PROTECTED] that is my 
company account. I used the wrong account. sorry and sorry for pool 
english
 
 


[LARTC] HTB + BRIDGE QUESTION!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! HELP!!!!!!!!!!!!

2003-07-17 Thread tanxuey




Hi everybody!
 
I am very glad to get htb test information from www.docum.org for the htb 
performance.
 
Today, I setup a bridge using brctl. my setup as 
following:
 
192.168.2.26 |  
| 
|
 |- | 
HTB+BR box  | 192.168.2.18
 |    
   eth0 
  | 
| eth1
    192.168.2.29 
|  
| 
|
 
 
I want to limit the traffics when i download data from 
192.168.2.18 to 26 or 29.
My script as following:
 
tc qdisc add dev eth0 root handle 1: htb default 
10
 
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 
10Mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1Mbit ceil 10Mbit prio 1
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 7Mbit ceil 10Mbit prio 2

tc class add dev eth0 parent 1:1 classid 1:12 htb rate 2Mbit ceil 10Mbit prio 3
 
tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst 
192.168.2.26/32 flowid 1:11
tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip dst 
192.168.2.29/32 flowid 1:12
 
 26 download from 18,26 can get 
900kbytes/s, but 26 and 29 download simultaneously, 26 get 400kbytes/s while 29 get 500kbytes/s .
 
i do not know why
 
any idea any sugestion ! please tell me,  I really appreciate your 
help!!!


[LARTC] Re[2]: local address routeable?

2003-07-17 Thread Julian Anastasov

Hello,

On Thu, 17 Jul 2003, Christian Stuellenberg wrote:

> If traffic from zone MASQ is addressed to one of the external internet
> addresses of one of the zone GOOD or DMZ, then it will currently get
> routed directly at HOST.  It is intended, that this direct routing is
> not done, but instead ALL traffic from zone MASQ becomes masqueraded
> out over the dynamic PPP connection to the internet, comes back over
> the CISCO line to HOST, then gets routed to the extern destination IP
> (in zone GOOD or DMZ) and when the reply from there comes back again
> to HOST, it should get routed over the CISCO internet connection and
> then back over the dynamic PPP connection, demasqueraded, and at last
> delivered to the original source in zone MASQ.
>
> This works up to the point, where the reply comes back to HOST.  Now
> I'm not able to tell HOST, that this reply should again routed out
> to the internet over the CISCO line and only demasqueraded if it comes
> in over the PPP connection (btw.  the demasquerading does also not
> occur if the reply gets not routed;  I assume, this is because the
> masquerding tables are waiting for a packet that comes in over the PPP
> connection and not on IF0 or IF1).

I think, I understand the setup. I'm still wondering what
is the end goal. I can only speculate:

Assumption 1. Hosts from GOOD want to see client from DynIP, not from
a.b.c.62. The solution: use SNAT with saddr=DynIP when talking to
GOOD because the default masquerade action is to use a.b.c.62
which is recommended from the routing. I assume GOOD and DMZ
do not care how the packet with saddr=DynIP appeared as long as
it looks as expected?

2. For some reason (even by introducing security problems) you
want packets with saddr=DynIP to walk the external path and
to reach GOOD. Is it needed? Is there a problem with the above
solution in #1?

> Regards,
> Christian

Regards

--
Julian Anastasov <[EMAIL PROTECTED]>

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Filter problem

2003-07-17 Thread Stef Coene
On Thursday 17 July 2003 10:49, Vitor Carlos Flausino wrote:
> I again.
> I have the following statements:
Maybe this can help :

http://www.docum.org/stef.coene/qos/faq/cache/41.html

Stef
-- 

[EMAIL PROTECTED]
 "Using Linux as bandwidth manager"
 http://www.docum.org/
 #lartc @ irc.oftc.net

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] prio + htb?

2003-07-17 Thread Stef Coene
On Sunday 13 July 2003 22:18, Esteban wrote:
> Stef, Lartc people,
>
> Hello, im using the above script for my network It works okay, the htb
> assigns the BW i want for outgoing traffic. But now, im looking foward
> giving priority to the packets on the first class under the second, i mean
> the first class packets leave the interface first than the second class.
> How do i apply that without loosing my conf?
Using different prio's can be tricky.  It can speed up some packets, but at 
the same moment, creating extra delays for the same packets if you send too 
much of them.
At the same time, you have to be carefully with the different rates for the 
child classes.  Make sure the sum is not more then the parent rate.  
Otherwise it can be difficult to find out what wil happen.

Stef

-- 

[EMAIL PROTECTED]
 "Using Linux as bandwidth manager"
 http://www.docum.org/
 #lartc @ irc.oftc.net

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] slowing down traffic to a certain port

2003-07-17 Thread Stef Coene
On Sunday 13 July 2003 13:21, Radu Maurer wrote:
> This is my first attempt at understanding lartc:
>
> I want to throttle outgoing bandwidth fo a certain tcp port and leave
> other traffic the way it was.
>
> so I put a prio qdisc at the root of eth0 (dummy priomap since i want to
> use filters to switch bands):
> $ tc qdisc add dev eth0 root handle 1: prio bands 2 priomap 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
>
> then attach a tbf qdisc at 1:2 :
> $ tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 2kbit buffer 100
> limit 300
>
> now i want traffic to port 4662 to be enqueued to the tbf qdisc:
> $ tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip sport
> 4662 0x flowid 1:2 but it doesn't work:
> RTNETLINK answers: Invalid argument
See lartc.org and docum.org for more information / scripts / tips about 
traffic shaping.

Stef

-- 

[EMAIL PROTECTED]
 "Using Linux as bandwidth manager"
 http://www.docum.org/
 #lartc @ irc.oftc.net

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] OUTPUT chain marking after or before routing?

2003-07-17 Thread [EMAIL PROTECTED]
Hi Martin, Catalin, Chijioke,

This subject intrigues me greatly and is closely related to a post of
just a few days ago:




> >+--++---+
> >| eth1   192.168.1.1   || 192.168.1.250 |
> >| eth1:1 192.168.1.101 ||   |
> >+--++---+
> >
> >
> >iptables --append OUTPUT --table mangle --jump MARK --set-mark 0x2
> >ip rule add fwmark 0x2 table 2
> >ip route add 192.168.1.0/24 dev eth1 src 192.168.1.101 table 2
> >ip route flush cache
> >
> >
> >telnet 192.168.1.250 ; and tcpdump gives src ip address as
> >192.168.1.1
> >
> >
> >ip rule add to 192.168.1.250 table 2
> >ip route flush cache
> >
> >
> >telnet 192.168.1.250 ; and tcpdump gives src ip address as
> >192.168.1.101

> According to my reading of the KPTD (and my understanding), packets
> generated on the local machine have already been routed by the time the
> OUTPUT chain is traversed.  See:
> 
>   http://www.docum.org/stef.coene/qos/kptd/
i have spent alot of time looking at this diagram and don't understand
what happens when. curiously, to my post patrick McHardy was kind enough
to test and:

On Sun, 2003-07-13 at 23:43, Patrick McHardy wrote:
> I tested your setup and it works fine (with 2.5 though). Are you sure 
> you have
> CONFIG_IP_ROUTE_FWMARK enabled for your running kernel ? ip rule won't
> give errors if not ..

very interesting, and i have yet to make it work here, although i
haven't debugged it yet

>  : have u tried putting it on the FORWARD chain??
> 
> Unfortunately the FORWARD chain will not work if these are locally
> generated packets.
yup.

> 
> I see two potential approaches to this problem:
> 
>   - invert your logic; main routing table uses ppp0 gateway IP as default
> gateway, mark all traffic passing through your router box, and use
> "ip rule add fwmark $MARK table $INTERNET" with another routing
> table for the Internet-bound traffic.
martin, this is pure genius

> 
>   - send all locally generated traffic via ppp0; "ip rule add iif lo
> table smtp" and watch all traffic generated on the local machine leave
> via ppp0.  You'll want to add the locally connected networks to table
> smtp.
can you comment why this is -- 

ip rule to xxx.xxx.xxx.xxx table n

works, and 

iptables fwmark y table n

doesn't? is it because OUTPUT checked the rule while the packet was
"generated" locally, but not after it was marked? 

1000 thanks


charles 

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] OUTPUT chain marking after or before routing?

2003-07-17 Thread Martin A. Brown
Catalin,

>When I try to connect to a smtp port somewhere in the Internet, tcpdump show
>me that these packets go to the eth2 interface (the main table default
>route). I don't know where is my mistake but it seems that the marking in
>the OUTPUT chain occurs AFTER and not BEFORE routing. Is this a correct
>behaviour? How can I solve my problem? Please help!

According to my reading of the KPTD (and my understanding), packets
generated on the local machine have already been routed by the time the
OUTPUT chain is traversed.  See:

  http://www.docum.org/stef.coene/qos/kptd/

 : have u tried putting it on the FORWARD chain??

Unfortunately the FORWARD chain will not work if these are locally
generated packets.

I see two potential approaches to this problem:

  - invert your logic; main routing table uses ppp0 gateway IP as default
gateway, mark all traffic passing through your router box, and use
"ip rule add fwmark $MARK table $INTERNET" with another routing
table for the Internet-bound traffic.

  - send all locally generated traffic via ppp0; "ip rule add iif lo
table smtp" and watch all traffic generated on the local machine leave
via ppp0.  You'll want to add the locally connected networks to table
smtp.

-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] OUTPUT chain marking after or before routing?

2003-07-17 Thread Chijioke Kalu


have u tried putting it on the FORWARD chain??

K

But how can I bind these rules to a interface when I don't know to what
interface the locally generated packets will arrive? In fact, this is the
purpose of marking the packets: to route them to the ppp0 interface.
- catalin -

- Original Message -
From: " ?" <[EMAIL PROTECTED]>
To: "Catalin Borcea" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2003 9:37 AM
Subject: Re: [LARTC] OUTPUT chain marking after or before routing?
> Well catalin, try to add theese rules with the in the prerouting chain
> but bind theese rules with the interfaces you have.
> Without binding netfilter rules with interfaces  it will not work, and
> you'll get the results you allready got.
> Catalin Borcea wrote:
>
> >Hello,
> >I tried to mark the packets in the PREROUTING chain but still doesn't
work.
> >Now the packets are no marked anymore when they go out by the eth2
> >interface. When I marked them in the OUTPUT chain they arrived also to
the
> >eth2 interface but marked. According to the docs the PREROUTING chain is
not
> >traversed by locally generated packets so, I don't know how this works
for
> >you. Maybe you have forwarded packets and not locally generated packets.
> >
> >
>
>
>
>
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] Re[2]: local address routeable?

2003-07-17 Thread Christian Stuellenberg
> "Christian" == Christian Stüllenberg <[EMAIL PROTECTED]> writes:
> "Julian" == Julian Anastasov <[EMAIL PROTECTED]> writes:
Hello,


Christian> I've got a problem to set up a configuration that shoud
Christian> allow to route packets that come in over a certain
Christian> interface(s) IF1 that then should go out to another
Christian> interface IF2 but are addressed to the local address of
Christian> interface IF3.  So only if packets for the address of
Christian> interface IF3 come in over interface IF3 they should be
Christian> locally accepted.
Julian> Yes, you have a big problem. Starting from kernels 2.4
Julian> and above the routing requires valid source IPs for output
Julian> routes. Even if you deliver locally the incoming traffic
Julian> your servers can not generate reply if the src IP is not
Julian> local IP.  What I do not understand from your posts is
Julian> what is the main goal? Also, what means "..."? Please,
Julian> draw picture with all wires and all kinds of hardware
Julian> involved: hubs, routers, subnets.

Ok, let me give you some more details.  It's even more complicated as
my original picture.

So the layout looks like:


  I  

  N  

  T  +---+
ISPB-ptp--CISCOa.b.c.1/30--a.b.c.2/30+...+a.b.c.62/28---GOOD
  E  |   .   |
 | HOST  +a.b.c.14/29---DMZ
  R  |   |
 |   |
  N ISPA-ptp--PPPOE--dynIP/32+.masq..+192.168.0.1/24---MASQ
 +---+
  E  

  T  


No more hubs or switches envolved in the routing.  All zones can only
"talk" to each other over HOST.

HOST has got several hardware interfaces.  One to a zone called DMZ on
networkinterface IF0 with IP0 and Submask NM0.  Another to a zone
called GOOD on IF1 with IP1/NM1.  Then a zone called BAD on IF2 with
IP2/NM2.  Additionally a zone MASQ on IF3 with IP3/NM3 and another
interface IF4.  That's the hardware layout.

Zone GOOD, DMZ and BAD all have extern routeable IP-addresses.  The
zone BAD is quite small and in it is also a CISCO with a ptp
connection to the ISP A.  Zone MASQ is something of the form
192.168.0.0/24.  At IF4 a pppoe-modem is attached so that over this
pppoe line a dynamic (extern routable) IP address IP4 is attached over
a ptp connection to the ISP B.

So, for the zones GOOD and DMZ the default gateway is a.b.c.1 and for
the zone MASQ the default gateway is the ptp-peer of the PPPOE
connection.  Everything that goes out over the PPPOE connection gets
masqueraded.

So far so good.

If traffic from zone MASQ is addressed to one of the external internet
addresses of one of the zone GOOD or DMZ, then it will currently get
routed directly at HOST.  It is intended, that this direct routing is
not done, but instead ALL traffic from zone MASQ becomes masqueraded
out over the dynamic PPP connection to the internet, comes back over
the CISCO line to HOST, then gets routed to the extern destination IP
(in zone GOOD or DMZ) and when the reply from there comes back again
to HOST, it should get routed over the CISCO internet connection and
then back over the dynamic PPP connection, demasqueraded, and at last
delivered to the original source in zone MASQ.

This works up to the point, where the reply comes back to HOST.  Now
I'm not able to tell HOST, that this reply should again routed out
to the internet over the CISCO line and only demasqueraded if it comes
in over the PPP connection (btw.  the demasquerading does also not
occur if the reply gets not routed;  I assume, this is because the
masquerding tables are waiting for a packet that comes in over the PPP
connection and not on IF0 or IF1).


Regards,
Christian

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] Filter problem

2003-07-17 Thread Vitor Carlos Flausino
I again.
I have the following statements:
#Initializing traffic control...
tc qdisc add dev br0 root handle 1:0 htb
#Loading queue disciplines for plis230 network...
tc class add dev br0 parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit
#Loading queue disciplines for pmad048 network...
tc class add dev br0 parent 1:1 classid 1:20 htb rate 30kbit ceil 30kbit
#server queue
tc class add dev br0 parent 1:20 classid 1:21 htb rate 6kbit ceil 30kbit
tc filter add dev br0 protocol ip parent 1:0 prio 1 u32 match ip dst 
57.227.233.3 flowid 1:21
tc qdisc add dev br0 parent 1:21 handle 200:0 sfq perturb 10

--After pinging host 57.227.233.3 a while why I get the result of 0 
packets sent through that filter?

bridge:/etc/rc.d # tc -s -d qdisc show dev br0;tc -s -d class show dev br0
qdisc htb 1: r2q 10 default 0 direct_packets_stat 128 ver 3.10
Sent 20832 bytes 128 pkts (dropped 0, overlimits 0)
class htb 1:1 root rate 512Kbit ceil 512Kbit burst 2254b/8 mpu 0b cburst 
2254b/8 mpu 0b level 7
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 28187 ctokens: 28187

class htb 1:20 parent 1:1 rate 30Kbit ceil 30Kbit burst 1637b/8 mpu 0b 
cburst 1637b/8 mpu 0b level 6
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 349439 ctokens: 349439

class htb 1:21 parent 1:20 prio 0 quantum 1000 rate 6Kbit ceil 30Kbit 
burst 1606b/8 mpu 0b cburst 1637b/8 mpu 0b level 0
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 1714132 ctokens: 349439

Thankx a lot,
-vcf
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] masquerade and tc problem

2003-07-17 Thread Balint Laszlo BILLER
Hi,

My friend uses ipchains with kernel 2.4.21 :) It's funny but it's true. The
problem is that he marks the packets and after this the tc filter doesn't
catch them.
ipchains -A input   -s 192.168.1.41/28 -j ACCEPT -m 0x2 -t 0xff 0x2
ipchains -A forward -s 192.168.1.41/28 -j MASQ  -m 0x2
ipchains -A input   -s 192.168.1.240 -j ACCEPT -m  0x3
ipchains -A forward -s 192.168.1.240 -j MASQ -m  0x3
And the filter:
tc filter add dev eth0 protocol ip parent 1:0 handle 2 fw classid 1:2
And after all no packets traverse the following class:
tc class add dev eth0 parent 1:0 classid 1:2 htb rate 1kbit ceil 2kbit prio
20
(rates are examples only for testing).
Any ideas?
Thanks,
Balint Laszlo BILLER, .:[=SysNet=]:.

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] OUTPUT chain marking after or before routing?

2003-07-17 Thread ???????? ?????
Then you have to bind theese rules to both of your ethernet interfaces 
assuming that the smtp traffic you want to mark arrives on both of your 
ethernet interfaces.
To do that you have to specify netfilter rules once for your first 
interface and once for your second interface.
I know that it looks complicated a little bit but it'll work.

Catalin Borcea wrote:

But how can I bind these rules to a interface when I don't know to what
interface the locally generated packets will arrive? In fact, this is the
purpose of marking the packets: to route them to the ppp0 interface.
 



___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] OUTPUT chain marking after or before routing?

2003-07-17 Thread Catalin Borcea
But how can I bind these rules to a interface when I don't know to what
interface the locally generated packets will arrive? In fact, this is the
purpose of marking the packets: to route them to the ppp0 interface.

- catalin -

- Original Message -
From: " ?" <[EMAIL PROTECTED]>
To: "Catalin Borcea" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2003 9:37 AM
Subject: Re: [LARTC] OUTPUT chain marking after or before routing?


> Well catalin, try to add theese rules with the in the prerouting chain
> but bind theese rules with the interfaces you have.
> Without binding netfilter rules with interfaces  it will not work, and
> you'll get the results you allready got.
> Catalin Borcea wrote:
>
> >Hello,
> >I tried to mark the packets in the PREROUTING chain but still doesn't
work.
> >Now the packets are no marked anymore when they go out by the eth2
> >interface. When I marked them in the OUTPUT chain they arrived also to
the
> >eth2 interface but marked. According to the docs the PREROUTING chain is
not
> >traversed by locally generated packets so, I don't know how this works
for
> >you. Maybe you have forwarded packets and not locally generated packets.
> >
> >
>
>
>
>


___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/