[buug] routing

[Michael Paoli]

Yes, there's probably (almost certainly) a way to do it.  Unfortunately
I find at least a slight bit of ambiguity regarding the description, so
hopefully I'm making correct guesses/assumptions regarding the scenario
described.

First the easy part:
a wants to "talk" to c, and must do so via b
The answer to that part, is as you mention, simple routing (route on a
to c is specified via b) - or at least it may be that simple in most
scenarios.  Likewise, if traffic from c to a must go via b, the
appropriate routing would be set up on c (or somewhere between c and
before b, to route via b).  Note also that possibility of asymmetric
routing may or may not have to be handled specially on a and/or c (for
example, on LINUX, it's relatively trivial (simple flags in /proc
filesystem) to filter whether or not traffic inbound on external
interfaces is accepted or dropped(/rejected?) if the interface does not
correspond to the interface that would be used to route packets to the
source IP of the incoming packet).

Then we get a bit beyond just routing (and filtering):
I'm not sure I'm interpreting your description correctly, but presuming
if a, in order to talk to c, sends packets with destination of c's IP
and port 7100 (which are routed via b), then b can handle the packet
mangling to change those to destination port 443, and pass those on
to/towards c.  Likewise if return IP is also via b, it could also do the
relevant mangling for the return traffic.  Since you mention b is a
LINUX system, b could handle that [iptables(8) for LINUX >=2.4.x or
ipchains(8) for LINUX 2.2.x, etc.].

Anyway, something like that would handle the basic port mangling.
However, since we're talking web server (presumably https), routing and
port mangling alone may not be quite sufficient, as there is data
payload (most notably HTTP/HTTPS headers) which may be problematic if
they're not also suitably translated.  If that data needs to also be
suitably dealt with, the simplest solution would probably be to use a
suitable HTTP/HTTPS proxy on b.  On the other hand, if c doesn't care
about precisely correct HTTP/HTTPS headers (e.g. Referer, Host), and a
doesn't care about HTTP/HTTPS links in content returned (e.g.
referring/defaulting to port 443 on c when a reached c via port 7100),
then using simple port mangling may be the more simple implementation -
but it may also violate the Principle of Least Surprise (especially if
content on c changes - adding links to pages that didn't earlier contain
links, and then a wants to follow those links).

Anyway, that's my take/guestimate/analysis of the scenario presented -
at least at a quick first glance.
route can handle the basic routing
ipchains(/iptables) can cover the port mangling
suitable proxy will likely also cover more application level data
Also, the LINUX iproute package can handle much more complex routing
(e.g. if traffic from a with destination IP of c needed to handle
different routes based on destination port).

> From: johnd <john at jjdev.com>
> To: buug at weak.org
> Message-ID: <20031117162700.GA2698 at stang.jjdev.com>
> Subject: [buug] routing
> Date: Mon, 17 Nov 2003 08:27:00 -0800

> I have  box a that needs to get to box c through box b

> so box a sets a static route to box c using box b as as gateway

> the problem
> box a needs to get to port 443 on box c but can only get to
> box b (the gateway) on 7001

> is there a way I can set this up?

> I don't know if this matters but:
> box a is a appserver running Solaris, box b is a linux box, and box c
> is a third party web server
> box a is behind two firewalls, and box b is in the 'DMZ'
> my fall back plan is to use squid and run it on port 7001...

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree