At 10:13 04/10/00 +0200, Marc Furrer wrote:
>Well redirect is usually done at HTTP level. The client receives a redirect
>message and will then establish a new connection the the other server.
>Hence you
>firewall must allow connection to that other server too from WAN.
that's true and must be kept in mind. however, redirect is possible at IP
level,
in which case his is "NAT-in" (instead of the traditionnal NAT-out). this
redirect is done when the packet is received and before any filtering is
performed,
so the state table is coherent. the filter never sees the original port 80.
so, if you nat-in port 80 to port 8080, here's what happens :
packet going to port 80 is rewritten to go to port 8080
filter sees pcket going to 8080. it checks its rules/state table
it lets it go (if permitted).
server responds, using src port 8080 (its own port).
filter sees a packet with src port 8080.
it searches the state table for a matching entry.
it finds one and lets the packet go.
the nat module sees the packet and checks its state table
it finds a matching entry and changes the src port to 80
etc etc.
note that the situation is the opposite for NAT-out: the filter sees the
firstpacket before
the NAT module. This must be kept in mind when configuring IP filtering.
for example, with ip filter, rdr is used to nat-in packets. in this case,
one should allow
the incoming packets by specifying the mapped address/port, not those
specified by the
client. so if you redirect web traffic going to 1.2.3.4 port 80 to 10.0.0.1
port 8000, you need
to allow requests going to 10.0.0.1 port 8000, eventhough no such packets
should exist
on the internet!
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
