As I've already said in the old thread, the problem is that the webserver
need to route the client's packet through the correct FW, which is not
simple.
You can NAT clients packets on FW2 to map their addresses to some
given class, and add a route to this class on your server. You can have NAT
either on FW2 or in the outside. The latter requires some work, but it
is ok (I can't see why it won't work).
For example, assume you wanna use 10.* for the clients (assuming these
are not used in your internal net. so you're using 192.168.... for example).
then you add a "map" on FW2 internal interface to convert the client's addr
to 10.* for the specific protocol/port. On your server, configure a static
route
so that packets going to 10.* go to FW2. This should not be hard to do.
At 22:34 24/02/01 -0800, Dennis Dai wrote:
>Sorry for the lengthy message and cross-posting to ipfilter list. Please
>bear with me :-)
>[snip]
>
>1. C -> FW2-E
>2. FW2 doing rdr => C -> W
>3. W -> C
>4. it goes to FW1 because that is the default GW
>5. *FW1 rewrite the packet to FW1-E -> C
>6. C is confused: I sent C -> FW2-E but why I get FW1-E -> C ???
>
>[*] I'm not sure whether FW1 will rewrite the packet because it didn't
>see SYN, FW2 saw it. NAT implies state, right?
It might rewrite the packet if you have NAT for the server, but it won't do
what you want. It will be considered as a connection initiated from your
server.
>OK, we can add more than one default route on the web server, but they
>must be of different metrics and they are tried from low to high (am I
>right on this?). So as long as both our FWs are up, the packet will go
>to the lowest metric, which is FW1-I.
That's right.
>[snip]
>
>What I like to see is whether we can combine FW2 and NAT:
>
>1. C -> FW2-E
>2. FW2 doing rdr *and map*: C -> FW2-E becomes FW2-I -> W
>3. W -> FW2-I
>4. FW2 rewrite back: W -> FW2-I becomes FW2-E -> C
>
>Note that step 2 above is not bimap. I think Darren introduced new
>syntax in 3.4.x to allow:
>
>rdr ifX from ip1/m1 to ip2/m2 port = xx -> ip3 port xx
>
>If it can be writen as:
>
>rdr ifX from ip1/m1 to ip2/m2 port = xx -> from ip3/m3 to ip4/m4 port xx
Use 2 different rules: a map and an rdr.
- an rdr on the external interface to redirect traffic to the server
- a map on the internal interface to convert clients addresses.
>PS. Mouss suggested to use an ALG.
I've suggested that cos' it's simple. but (security put apart)), it's
equivalent to a map+rdr.
> But we are kind of reluctant to go
>this way because:
>1. We have to open up ports on the firewall.
A proxy doesn't require opening a port that is not already open:)
if you allow traffic to your server/port=80, then running a proxy on
port 80 to redirect traffic to your server/port=80 doesn't harm.
It's quite the opposite, since IP based attacks are blocked by
your FW (your FW will handle IP options and fragmentation and....).
>2. For socks proxy you need socksified client, right? For web cache
>proxy like squid it should be OK for web access but what about other
>services like DNS and SMTP?
I don't socks... so...
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
