(Stupid?) fastrouting question

[Lucio De Re]

The question: Given a net server running squid, bind and sendmail (I
think that's about it), I want all "web" traffic (tcp ports 80 and 443)
to go to a router other than the "default" and return by the same path
(there's NAT on there, so that makes things a little more difficult).
All other traffic should ideally go undisturbed. The host has three
ethernet interfaces, one internal, another to the external network on
which our primary external router sits and a third that could be used
for the alternative router, if necessary. I'd mildly prefer the two
routers to reside on the same external network, but I have made
provision otherwise.

I thought Darren's ipfilters would do the trick, but I haven't yet found
the right combination of simple rules to get it right (I have tried a
few alternatives that looked promising in theory). Since then, I've
considered using lo0 as the "default" interface and the IP filters
between it and the two routers (I can place them on distinct physical
networks, if necessary) but the experimenting is impractical until next
week and I have a feeling I don't really know that what I'm suggesting
makes any sense.

There no doubt is an easier approach, but I lack the understanding to
identify it without help. Anyone done this already? How?

Ideally, I'd want a squid appliance between the internal network and the
ADSL link, but I'm not aware that such devices exist, so if anyone knows
of one such, please point me to that.

++L



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Lucio De Re
Ideally, I'd want a squid appliance between the internal network and the
ADSL link, but I'm not aware that such devices exist, so if anyone knows
of one such, please point me to that.

I'd expect a NAT rule like

rdr hme0 from 192.168.0.0/255 to any port=www -> localhost port 8080

to work (if hme0 is your internal interface).

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Alan Barrett]

Post by Lucio De Re
The question: Given a net server running squid, bind and sendmail (I
think that's about it), I want all "web" traffic (tcp ports 80 and
443) to go to a router other than the "default" and return by the
same path (there's NAT on there, so that makes things a little more
difficult).

[...]

Post by Lucio De Re
Ideally, I'd want a squid appliance between the internal network and
the ADSL link, but I'm not aware that such devices exist, so if anyone
knows of one such, please point me to that.

Make your own "squid appliance". Here's an attempt using "pf".
(Most of this is adapted from a working system, but some of it
is untested.)

# in squid.conf:

#
# act as an interception proxy
#
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

# in pf.conf:

#
# There are some places where we are not allowed to use
# the "self" keyword, but are allowed to use a table name.
# So define a table to DTRT.
#
table <self> const { self }

#
# destinations for which port 80 connections should
# not be molested:
#
table <allow80> { self, 192.0.2.0/24 }

#
# Other rules intercept traffic on TCP port 80 and divert it
# to interface lo0 using 'pass out ... route to lo0 ... tag ...'
# rules. Here, we grab those packets and divert them to squid
# using 'rdr on lo0' rules.
#
##rdr on lo0 \
## proto tcp from any to any \
## tagged "interceptsquid" \
## -> 127.0.0.1 port 3128
# XXX: The above (commented out) rule doesn't work, so
# we use the following rule as a crude approximation
# to what we want (using 'to ! <self>' instead of 'tagged
# "interceptsquid"')
rdr on lo0 \
proto tcp from any to ! <self> port 80 \
-> 127.0.0.1 port 3128

#
# add "allow80" tag to port-80 traffic that should not be molested
#
pass out on ! lo0 \
proto tcp from any to <allow80> port 80 \
tag "allow80" \
keep state
pass out on ! lo0 \
proto tcp from any to any port 80 \
user { squid } \
tag "allow80" \
keep state

#
# TCP port 80 connections that were not tagged with "allow80"
# above are now tagged with "interceptsquid" and diverted to the
# lo0 interface. A "rdr" rule will pick them up there.
#
pass out on ! lo0 route-to lo0 \
proto tcp from any to any port 80 \
! tagged "allow80" \
tag "interceptsquid" \
keep state

#
# Apply policy routing to "web" traffic on the
# external interface.
#
pass out on $external_interface \
route-to $special_interface $special_router \
proto tcp from any to any port { 80, 443 } \
keep state

--apb (Alan Barrett)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Hi Lucio,

I think it might help if you were able to do an ascii diagram
of how the network is constructed and point out where you
want the traffic to go, which box is running NetBSD, etc.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lucio De Re]

Post by Darren Reed
I think it might help if you were able to do an ascii diagram
of how the network is constructed and point out where you
want the traffic to go, which box is running NetBSD, etc.

Thank you to all who helped me (and those who might have wanted to).

It turns out to be as trivial as I wanted it, although it will probably
still be years before I really get my mind around packet filtering etc.

In summary:

# cat /etc/ipf.conf
pass in all
pass out all
pass out quick on fxp1 to ex0:192.168.4.129 proto tcp from any to any \
port = 80
pass out quick on fxp1 to ex0:192.168.4.129 proto tcp from any to any \
port = 443

(excuse the poor formatting - evolution doesn't have an intuitively
obvious place where to change the line length).

# cat /etc/ipnat.conf
map ex0 196.30.44.148/32 -> 0/32 portmap tcp 10000:20000

eventually did the trick. I had tried "block" instead of "pass" because
I thought I had to prevent the packets from leaving on the wrong
interface (go figure!) and I misunderstood the role played by the target
IP address in the "to" clause altogether.

The NAT "map" also came in late (I misguidedly tried "rdr" at first).

Lots of little mistakes in just a very few lines. But now it works
better than adequately. I won't be able to run a web server on this
host, but I think I can cope with that :-)

Again, thanks everyone, specially the various developers of very sound
and reliable software.

++L



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de