>As no solution appeared, I try again, here is my config (figure
>clarified by Darryl Miles)
>
> 10.67.28.0/24
> -----------+----------------------------------+-----------
> eth1 | 10.67.28.2 eth1 | 10.67.28.1
> +-----+-----+ +-----+------+
> | FIREWALL | | HOST |
> | | | |
> +-----+-----+ +-----+------+
> eth0 | 10.67.27.2 eth0 | 10.67.27.1
> -----------+----------------------------------+-----------
> 10.67.27.0/24
>
>
>The question:
>From the host, how to force a packet destined to 10.67.27.1 to go
>through the firewall since
>
>route add -host 10.67.27.1 gw 10.67.27.2 dev eth0
>
>is not enough ?
Ah, I had presumed the IP you were trying to route to is on FIREWALL and
not on HOST, by using the non-obvious path/interface selection to get
there.
What you want is simply not normal, since what you are asking is the
kernel treat the packet as non-local when it sends it out on eth1 to
FIREWALL and then treat it as local when it arrives back in again at
eth0 on HOST. It is really make up your up mind time, is the address to
be accepted locally by host or not?
I don't believe any amount of configuration using stocks tools or kernel
will achieve what you want, unless you can move the 'local' table from
rule '0' to rule '1' and insert your own table before it. However I
suspect table number 0, the local table is hardcoded to be 0 in the
kernel for the very good reasons above that local processing is done
first BEFORE a forwarding decision is made.
I can however offer as possible solution:
10.67.28.0/24
-----------+----------------------------------+-----------
eth1 | 10.67.28.2 eth1 | 10.67.28.1
+-----+-----+ <<<<<<< +-----+------+
| | v ^ | |
| FIREWALL | v | HOST +--- SLIP link
--+ 10.67.27.3
| | v ^>>> | |
+-----+-----+ >>>>>>> +-----+------+
eth0 | 10.67.27.2 eth0 | 10.67.27.1
-----------+----------------------------------+-----------
10.67.27.0/24
Configure HOST with a policy route or two.
The IP address of 10.67.27.3 would be setup as a SLIP link through a
pseudo-tty device, loopbacked to a process on the HOST machine. This
should only be any good as an interface which can sink packets to, this
maybe easier to achieve by using policy routing and bitbucket routing
entries to an arbitary address (which isn't considered local to either
HOST or FIREWALL).
So it depends if you want the destination test address to act as a
bitbucket or have a real application on the end of it.
Why not use another machine in this excercise? Use tcpdump on the
return interface of FIREWALL, from HOST to monitor what is happening.
Maybe this is a dumb comment from me, like if you could you would have
by now :)
--
Darryl Miles
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
