Re: Pb : Routing with multiples interfaces
Frédéric Massot wrote:
> Hans van Kranenburg wrote:
>> Hey,
>>
> [...]
>>
>>> # LEASED LINE
>>> ip rule add prio 203 from $NETWORK_LL/$PREFIX_LL table 203
>>> ip route add default via $GATEWAY_LL dev $INTERFACE_LL src $IP_LL proto
>>> static table 203
>>> ip route append prohibit default table 203 metric 1 proto static
>>
>> The src $IP_LL is specified in the ip route add line for table 203. So
>> the source address for the packet must be known and match $IP_LL,
>> otherwise this route will be ignored.
>>
>> I seems you used this nice howto: http://www.ssi.bg/~ja/nano.txt Read
>> section '2.3.3 Setup of the default routes' again, carefully: "The
>> tricky part is, what the patches are doing here: They look at the local
>> source address" etc... is what I mean.
>>
>>
>>> # SMTP MARK
>>> ip rule add prio 103 fwmark 0x25 table 203
>>
>>
>> So table 203 gets looked up, but the default route to $INTERFACE_LL
>> won't get used. Instead one route of the multipath default route will be
>> chosen.
>>
>>
>>> ip rule add prio 222 table 222
>>> ip route add default table 222 proto static \
>>> nexthop via $GATEWAY_DSL1 dev $INTERFACE_DSL1 weight 10 \
>>> nexthop via $GATEWAY_DSL2 dev $INTERFACE_DSL2 weight 10 \
>>> nexthop via $GATEWAY_LL dev $INTERFACE_LL weight 1
>>
>>
>> I solved this problem by creating two extra routing tables. By directing
>> traffic which routing is forced to an outgoing line to a routing table
>> without the src address specified it matches a connectino that get
>> initiated.
>>
>
> I modified the STMP MARK rule and I created a new routing table (204),
> like this :
>
> #SMTP MARK
> ip rule add prio 103 fwmark 0x25 table 204
> ip route add default via $GATEWAY_LL dev $INTERFACE_LL proto static
> table 204
>
> But, I have the same problem :
>
> # tcptraceroute -d -i eth2 -s 192.168.2.1 smtp.juliana-multimedia.com 25
> debug: device set to eth2
> debug: Discovered interface eth0 with address 192.168.1.1
> debug: Discovered interface eth1 with address 192.168.0.1
> debug: Discovered interface eth2 with address 192.168.2.1
> debug: Determined source address of 192.168.1.1 to reach 213.223.240.194
>
> The selected source address for the eth2 interface is 192.168.1.1, this
> is wrong, the good source address is 192.168.2.1
>
> I don't understand why the multipath default route is chosen. :o(
Hmm, right. I just tried the same here on the box i used as an example
in my previous post:
kermit.1 ~# tcptraceroute -d smtp.juliana-multimedia.com 25
debug: tcptraceroute 1.5beta6, i686-pc-linux-gnu
debug: Compiled with libpcap 0.7.2, libnet 1.1.2.1 (API 110)
debug: entering getinterfaces()
debug: ifreq buffer set to 32
debug: Successfully retrieved interface list
debug: Discovered interface lo with address 127.0.0.1
debug: Discovered interface eth0 with address 172.20.106.183
debug: Discovered interface eth1 with address 192.168.9.1
debug: Discovered interface eth2 with address 82.92.101.131
debug: Discovered interface ppp0 with address 145.94.37.96
debug: leaving getinterfaces()
debug: Determined source address of 145.94.37.96 to reach 213.223.240.194
So, that's the wrong one. It should be 82.92.101.131 according to my
routing configuration.
But... when i simply telnet:
kermit.1 ~# telnet smtp.juliana-multimedia.com 25
Trying 213.223.240.194...
Connected to smtp.juliana-multimedia.com.
Escape character is '^]'.
220 eole.juliana-multimedia.com ESMTP Postfix
And look at the network connections with e.g. iptraf i see the
connection was made using my eth2 (which isn't listed in my default
route) so the routing configuration must have done it's work.
Perhaps you should try to make connections with other tools also... I
can't explain this behaviour of tcptraceroute... :\
> Thes Linux Box receives the internal mail on its internal interface.
> Postfix/Amavis/Clamav/Spamassassin check this mail and sends it on the
> LL interface ($INTERFACE_LL - $IP_LL).
Why don't you use the -o smtp_bind_address option in Postfix? Much less
complex setup... When Postfix chooses to bind to a specific outgoing
address the routing tables will follow that and choose the right
interface according to it.
> I use these rules to mark the paquets :
>
> iptables -t mangle -A OUTPUT -o $INTERFACE_DSL1 -p tcp --dport 25 -j
> MARK --set-mark 0x25
> iptables -t mangle -A OUTPUT -o $INTERFACE_DSL2 -p tcp --dport 25 -j
> MARK --set-mark 0x25
> iptables -t mangle -A OUTPUT -o $INTERFACE_LL -p tcp --dport 25 -j MARK
> --set-mark 0x25
I don't think this is correct, but i'm not really sure. I guess it's
more appropriate to filter using the destination IP than using outgoing
interface names, because we don't know the -o interface yet here...
http://www.certconf.org/presentations/2002/Tracks2002Tutorials_files/FT-2B.pdf
The OUTPUT/mangle chain is Used to mangle packets created by the
firewall and gets hit before routing decision is made, so *before* we
know what source ip is used (unless it was specified explicitly).
>From the firewall
- Routing for source address
- OUTPUT, mangle
- OUTPUT, nat
- OUTPUT, filter
- Routing decision
- POSTROUTING, nat
- POSTROUTING, mangle
So probably using the destination IP for deciding which packets to mark
sounds like a better idea:
iptables -t mangle -A OUTPUT -o ! in.ter.nal/msk -p tcp --dport 25 -j
MARK --set-mark 0x25
Hans
Reply to: