TOS problem

TOS problem

[Marcin Giedz]

Hello

A few days ago I wrote post about "Ip:Port REDIRECTION problem". Since that 
time I have searched once again iptables HOW-TOs and find that one of the 
solutions for my problem is changing TOS to other value. This is done by 
simple rule:
iptables -t mangle -A PREROUTING -p tcp --dport 4000 -j TOS --set-tos 0x10
Next I redirect port 4000 from this router to another machine:
iptables -t nat -A PREROUTING -p tcp --dport 4000 -j DNAT 192.168.49.60:80

This works OK on router when this rule is being ran but when I dump (tcpdump) 
packtes on 192.168.49.60, "ToS" value is changed to 0x0. No any rules are 
being set on 192.168.49.60 - simple machine. Why "ToS" is changing? What do I 
wrong?

Thanks,
Marcin

Re: TOS problem

[Jörg Harmuth]

Marcin Giedz schrieb:
> Hello
> 
> A few days ago I wrote post about "Ip:Port REDIRECTION problem". Since that 
> time I have searched once again iptables HOW-TOs and find that one of the 
> solutions for my problem is changing TOS to other value. This is done by 
> simple rule:
> iptables -t mangle -A PREROUTING -p tcp --dport 4000 -j TOS --set-tos 0x10
> Next I redirect port 4000 from this router to another machine:
> iptables -t nat -A PREROUTING -p tcp --dport 4000 -j DNAT 192.168.49.60:80
> 
> This works OK on router when this rule is being ran but when I dump (tcpdump) 
> packtes on 192.168.49.60, "ToS" value is changed to 0x0. No any rules are 
> being set on 192.168.49.60 - simple machine. Why "ToS" is changing? What do I 
> wrong?

Your providing too little information, so nobody can help you - even if
he/she desired to do so.

Hmm, iptables isn't known for unreliability. Did you tcpdump on the
routers outgoing interface ? What about TOS there ?

I read your previous posting again, and your problem seems to be routing
or iptables (not really sure). Why do you think that setting TOS to
"Minimize-Delay" could help to solve your problems ?

Have a nice time,

Joerg

Re: TOS problem

[Marcin Giedz]

Hello,

> Your providing too little information, so nobody can help you - even if
> he/she desired to do so.
Maybe your are right.. I will try once again.

In my office we have 2 gateways. One of them GATEWAY1 is connected to one ISP1 
and it is also default gateway for almost all of our servers. I said "almost" 
because there is one server "service" where default gateway is GATEWAY2 
connected to another ISP2.

All of our customers run Services situated on "service" server  via GATEWAY2. 
But if GATEWAY2 is down or connection to ISP2 is broken I would like that 
customers can still connect to Services via GATEWAY1. So I need some kind of 
redirection on GATEWAY1 because I don't want to switch default gateway on 
"service" manually. However if GATEWAY2 is running OK some part of our 
customers can still run Services via GATEWAY1. My problem is:
how to route connections to "service" server passed via GATEWAY1? 
Packets MARK'ing work within kernel so can be used. Another way is changing 
TOS on GATEWAY1 for "these" packets and route them to "service".  

According to TOS description:
"The TOS target is used to set the Type of Service field within the IP header. 
The TOS field consists of 8 bits which are used to help in routing packets. 
This is one of the fields that can be used directly within iproute2 and its 
subsystem for routing policies. Worth noting, is that that if you handle 
several separate firewalls and routers, this is the only way to propagate 
routing information within the actual packet between these routers and 
firewalls. As previously noted, the MARK target - which sets a MARK 
associated with a specific packet - is only available within the kernel, and 
can not be propagated with the packet. If you feel a need to propagate 
routing information for a specific packet or stream, you should therefore set 
the TOS field, which was developed for this. "

So I changed TOS on GATEWAY1 to 0x10 and used is as "mark". TOS changing work 
OK on GATEWAY1, even on outgoing interface but on "service" server TOS value 
is still 0x0. So I can't route packets on "service" server back to GATEWAY1.

Maybe I try to do something REALLY strange but can't imagine another solution.

Thanks,
Marcin

Re: TOS problem

[Jörg Harmuth]

Marcin Giedz schrieb:
> Hello,
> 
> 
>>Your providing too little information, so nobody can help you - even if
>>he/she desired to do so.
> 
> Maybe your are right.. I will try once again.
> 
> In my office we have 2 gateways. One of them GATEWAY1 is connected to one ISP1 
> and it is also default gateway for almost all of our servers. I said "almost" 
> because there is one server "service" where default gateway is GATEWAY2 
> connected to another ISP2.
> 
> All of our customers run Services situated on "service" server  via GATEWAY2. 
> But if GATEWAY2 is down or connection to ISP2 is broken I would like that 
> customers can still connect to Services via GATEWAY1. So I need some kind of 
> redirection on GATEWAY1 because I don't want to switch default gateway on 
> "service" manually. However if GATEWAY2 is running OK some part of our 
> customers can still run Services via GATEWAY1. My problem is:
> how to route connections to "service" server passed via GATEWAY1? 

Just to summarize the important points. Main traffic goes via GW1 to
ISP1, but the server in question has as default GW GW2 which in turn has
default GW to ISP2. The problem is to forward incoming connection from
GW1 to GW2 (or your special service server), if customers connect to
service server via GW1.

> Packets MARK'ing work within kernel so can be used. Another way is changing 
> TOS on GATEWAY1 for "these" packets and route them to "service".  

Yes, almost for sure, it is possible to have a solution based on MARK
and / or TOS, but I don't believe that it's necessary.

You said in your posting "IP:Port REDIRECT problem", that you tried with
public IPs to no avail. Why public IPs ? If your GWs aren't connected to
each other somehow, I suggest to connect them with RFC1918 addresses and
 set the routes accordingly. You don't want to redirect from GW1 to GW2
via the internet, do you ?

Once the GWs are connected, I think the simple solution will be to use
DNAT and SNAT with iptables, 'cause I can't see anything, that needs
more effort. So it breaks down to curby's posting, which looks something
this style:

## On GW1
iptables -t nat -A PREROUTING -p tcp --dport 4000 \
   -i $INET_IFACE -j DNAT --to $IP_OF_GW2
## If FORWARD policy is not ACCEPT or you have a rule like
## ... -A FORWARD -j DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED \
   -j ACCEPT
iptables -A FORWARD -i $INET_IFACE -o $IFACE_TO_GW2 \
   -p tcp --dport 4000 --syn -j ACCEPT
## You need SNAT too, at least it's the save way
iptables -t nat -A POSTROUTING -o $IFACE_TO_GW2 \
   -p tcp --dport 4000 -j SNAT --to $IP_OF_IFACE_TO_GW2

So, if GW1 and GW2 are connected somehow and know how to route packets
to each other, the packets in question will reach GW2 with a source
address of GW1. If allowed by iptable rules, GW2 will forward / redirect
these packets to "service server" (maybe applying DNAT and SNAT too) and
everything should work.

HTH and have a nice time,

Joerg

Re: TOS problem

[Marcin Giedz]

Dnia wtorek, 26 lipca 2005 14:49, Jörg Harmuth napisa³:

Thanks so much Joerg .... one thing i didn't realized earlier - SNAT. Now it 
roks. Thanks once again.

Marcin


> Marcin Giedz schrieb:
> > Hello,
> >
> >>Your providing too little information, so nobody can help you - even if
> >>he/she desired to do so.
> >
> > Maybe your are right.. I will try once again.
> >
> > In my office we have 2 gateways. One of them GATEWAY1 is connected to one
> > ISP1 and it is also default gateway for almost all of our servers. I said
> > "almost" because there is one server "service" where default gateway is
> > GATEWAY2 connected to another ISP2.
> >
> > All of our customers run Services situated on "service" server  via
> > GATEWAY2. But if GATEWAY2 is down or connection to ISP2 is broken I would
> > like that customers can still connect to Services via GATEWAY1. So I need
> > some kind of redirection on GATEWAY1 because I don't want to switch
> > default gateway on "service" manually. However if GATEWAY2 is running OK
> > some part of our customers can still run Services via GATEWAY1. My
> > problem is:
> > how to route connections to "service" server passed via GATEWAY1?
>
> Just to summarize the important points. Main traffic goes via GW1 to
> ISP1, but the server in question has as default GW GW2 which in turn has
> default GW to ISP2. The problem is to forward incoming connection from
> GW1 to GW2 (or your special service server), if customers connect to
> service server via GW1.
>
> > Packets MARK'ing work within kernel so can be used. Another way is
> > changing TOS on GATEWAY1 for "these" packets and route them to "service".
>
> Yes, almost for sure, it is possible to have a solution based on MARK
> and / or TOS, but I don't believe that it's necessary.
>
> You said in your posting "IP:Port REDIRECT problem", that you tried with
> public IPs to no avail. Why public IPs ? If your GWs aren't connected to
> each other somehow, I suggest to connect them with RFC1918 addresses and
>  set the routes accordingly. You don't want to redirect from GW1 to GW2
> via the internet, do you ?
>
> Once the GWs are connected, I think the simple solution will be to use
> DNAT and SNAT with iptables, 'cause I can't see anything, that needs
> more effort. So it breaks down to curby's posting, which looks something
> this style:
>
> ## On GW1
> iptables -t nat -A PREROUTING -p tcp --dport 4000 \
>    -i $INET_IFACE -j DNAT --to $IP_OF_GW2
> ## If FORWARD policy is not ACCEPT or you have a rule like
> ## ... -A FORWARD -j DROP
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED \
>    -j ACCEPT
> iptables -A FORWARD -i $INET_IFACE -o $IFACE_TO_GW2 \
>    -p tcp --dport 4000 --syn -j ACCEPT
> ## You need SNAT too, at least it's the save way
> iptables -t nat -A POSTROUTING -o $IFACE_TO_GW2 \
>    -p tcp --dport 4000 -j SNAT --to $IP_OF_IFACE_TO_GW2
>
> So, if GW1 and GW2 are connected somehow and know how to route packets
> to each other, the packets in question will reach GW2 with a source
> address of GW1. If allowed by iptable rules, GW2 will forward / redirect
> these packets to "service server" (maybe applying DNAT and SNAT too) and
> everything should work.
>
> HTH and have a nice time,
>
> Joerg

TOS problem

[nedco]

Hi,  
 
i like to set on myrouter TOS 0x0( Normal-Service ) to some packets 
but found that on some of packets can't set TOS 
in example  
 
then i ping 62.73.77.8 i get pakets with tos 0x10 and can't set to 0x0  
 
table mangle 
Chain FORWARD (policy ACCEPT 1242M packets, 469G bytes) 
 pkts bytes target     prot opt in     out     source               destination

 4589 1075K TOS        all  --  *      *       0.0.0.0/0            62.73.77.8
        TOS set 
0x00 
 4489  919K TOS        all  --  *      *       62.73.77.8           0.0.0.0/0
         TOS set 
0x00 
 
on tcpdump get  
02:36:44.898854 62.176.107.193 > 62.73.77.8: icmp: echo request 
02:36:44.956965 62.73.77.8 > 62.176.107.193: icmp: echo reply [tos 0x10] 
 
Am I doing something wrong? 
 
mandrake Linux version 2.4.19-16mdksmp, iptables v1.2.6a 
10x in advance 
Nedko 

Re: TOS problem

[Maciej Soltysiak]

> on tcpdump get
> 02:36:44.898854 62.176.107.193 > 62.73.77.8: icmp: echo request
> 02:36:44.956965 62.73.77.8 > 62.176.107.193: icmp: echo reply [tos 0x10]
>
> Am I doing something wrong?
tcpdump on a different machine, if you're tcpdumping on a the iptables
machine tcpdump gets a copy of the packet, then it is mangled, so tcpdump
won't show that.

Regards,
Maciej

Re: TOS problem

[Nedko Nedev]

You are right but strange result i see then i set tos 0x10 for boot
directions
tcpdump i one direction eth1->eth1 show new tos but in eth0->eth1 not :))
and now i'm not absolute sure what
>>tcpdump gets a copy of the packet, then it is mangled

09:55:00.984707 212.5.150.58.27005 > 212.5.134.10.27015: udp 39 [tos 0x10]
09:55:00.993254 212.5.134.10.27015 > 212.5.150.58.27005: udp 176
09:55:01.035795 212.5.150.58.27005 > 212.5.134.10.27015: udp 39 [tos 0x10]
09:55:01.059674 212.5.134.10.27015 > 212.5.150.58.27005: udp 152
09:55:01.068017 212.5.150.58.27005 > 212.5.134.10.27015: udp 38 [tos 0x10]
09:55:01.113957 212.5.150.58.27005 > 212.5.134.10.27015: udp 39 [tos 0x10]
09:55:01.123299 212.5.134.10.27015 > 212.5.150.58.27005: udp 163
09:55:01.152040 212.5.150.58.27005 > 212.5.134.10.27015: udp 39 [tos 0x10]
09:55:01.190807 212.5.134.10.27015 > 212.5.150.58.27005: udp 148
09:55:01.193077 212.5.150.58.27005 > 212.5.134.10.27015: udp 39 [tos 0x10]
09:55:01.234989 212.5.150.58.27005 > 212.5.134.10.27015: udp 39 [tos 0x10]

Regards,
Nedko


----- Original Message -----
From: "Maciej Soltysiak" <solt@dns.toxicfilms.tv>
To: <nedco@unacs.bg>
Cc: <netfilter@lists.netfilter.org>
Sent: Wednesday, March 05, 2003 3:55 PM
Subject: Re: TOS problem


>
>
>
> > on tcpdump get
> > 02:36:44.898854 62.176.107.193 > 62.73.77.8: icmp: echo request
> > 02:36:44.956965 62.73.77.8 > 62.176.107.193: icmp: echo reply [tos 0x10]
> >
> > Am I doing something wrong?
> tcpdump on a different machine, if you're tcpdumping on a the iptables
> machine tcpdump gets a copy of the packet, then it is mangled, so tcpdump
> won't show that.
>
> Regards,
> Maciej
>
>
>