David Loysen wrote:
>
> Tracert (UDP) completes on either interface with a last hop of my routers
> outside the firewalls. The firewall has never shown up as a tracert hop, I
> assume by design.
>
> Tracert (TCP) fails on both because it isn't currently allowed. I am going
> to be working on this tonight and will let you know what happens. I'm
> guessing it will be the same as tracert (UDP).
>
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.]
