hummm.
either he NATs clients source addresses, and follow Bens words, in
whih case, everything will work,
or he doesn't NAT clients source addresses, and then as I said before,
it can't work.
having 2 addresses, 2 ports, ... on the webserver changes nothing. It's a
routing problem, so it doesn't depend on what addresses and ports are
configured
on the server itself, but on what addresses are to send replies to.
At 22:09 24/10/00 +0900, horio shoichi wrote:
>Thanks. Your reply clarified how your firewalls are working.
>
>
>Back to the point:
>
>Last time I proposed a solution based on two one to one NAT entries which you
>seem to have some difficulty with. So this time I broke it down to potential
>problem area and possible workarounds.
>
>Following is the list of potential problems I currently think of. If this list
>is off your problem, please post it here.
>
> <OT> Having two address is an essential requirement to find through
> which interface the request came in to determine what source address
> should be given to the responding packet. The other technique may be
> changing port address depending on passing router/firewall, but this
> technique will be outside of routing decision which bases sorely on
> destination address so it needs assistance of linux box because
> normal routing techniques don't work.
> </OT>
>
>1 Server software doesn't support two ip addresses
>
> If so, the software must be able to listen to two ports at the same time;
> if it is also impossible, then there is no way to color the packets to
> distinguish packet routes; the remaining chance is using replicating
> server.
>
>2 Operating System doesn't support ip alias
>
> Situation looks similar to above, but isn't. First, Operating Systems
> definitely
> supports more than two ports. And second, seriously, adding a NIC which
> takes
> different path from firewall guarantees the packets to have different ip
> address. Note responding packets are still dispatched to default route,
> not to
> the coming firewall directly.
>
>3 NAT doesn't allow two one to one static entries
>
> You are lucky, since you have linux box on the route. There are a few ways
> to overcome this problem using linux. I'll describe only a few here.
>
> o Stop NAT functions on firewall boxes. Instead, let IPMasquerade do NAT.
> It may be sufficient to replace one firewall NAT with IPMasquerade,
> though.
>
> o (This requires firewalls and linux box are not hub dispatched. In
> other words,
> linux box must have two heads each of which is directly connected to
> respective
> firewall. My knowledge on ipchains, ipfwadm, etc are absolutely nil.
> So I am not
> sure if this paragraph makes sense, or better alternative exists.)
> Depending on
> source address, linux determines outgoing interface, and submit the
> packet
> to the interface, thus to the firewall accordingly. Note that linux
> box must not
> modify the packet; it's the task of outer entity.
>
>4 ISP doesn't allow "spoofed" packets
>
> (Since it's not clear where the responce packets are lost, i.e., at
> NAT, ISP, or
> at client machine/firewall, this paragraph may not make sense depending
> on the
> situation.)
>
> From ISP's standpoint, outgoing packet that doesn' hold client's source
> address
> looks like a malicious activity. OTO, this sort of thing occurs commonly on
> network relocations. Contact ISP. if you can't persuade them, then
> contact the
> other ISP, and switch default route.
>
> If you still have problem here, then you may be able to resort to the
> second
> paragraph of above 3.
>
>If unfortunately you have to use different port, then you have to use the
>second
>paragraph of above 3, reading "source address" as "source port".
>
>
>
>horio shoichi
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
