Thanks for the quick reply.
On 2 Feb 99, at 1:09, Fuzzy Fox wrote about
"Re: [masq] IP Port Forwarding":
| Fred Viles <[EMAIL PROTECTED]> wrote:
| >
| > As for actually routing the masqueraded reply through the eth1
| > interface, is that even possible? Can the masquerade logic override
| > the default route?
|...
| Once a routing decision has been made (via the route table), the masq
| rules can only decide whether it should, or should not happen, or
| whether to invoke masquerading when the route is taken.
Yes, that's implied by the fact that the forwarding/masquerade rules
are associated with the outgoing interface. So this is also true
when a packet matches an existing entry in the masq table, right?
But in theory it might still be possible to explicitly direct the
packet to the interface associated with the masq IP address from the
table? It would have to have a gateway IP configured, but not be the
default route. Obviously the current masq code can't do this, of
course.
| It's possible that masq isn't quite set up properly in the problem
| given. Perhaps the masq box is trying to masquerade in multiple
| directions, which makes the target machine unable to recognize its own
| reply (because it looks like a different machine). Just a guess,
| really.
It would be really nice if masq could handle this case and we just
have to configure it right. But I don't think so. The problem is
that while routing only allows for one default route to the outside,
there are really two valid routes. So thanks to IPPORTFW,
connections can be made from the outside world to masq'ed machines
via either interface, and the replies can't similarly be routed back
via either interface.
| Anyway, the main issue is that, if you think the packets are going the
| wrong way, you have to fix the route table to do the right thing.
You can't, at least in 2.0.x kernels. You might be able to get
policy routing to do the right thing in 2.2.x kernels, depending on
your situation. That might help Chris, who would probably be happy
to unconditionally route source port 25 and 110 traffic from his
email server to his ISDN link.
| You
| can't fix it in the masq rules; they can't change that behavior. If a
| machine is sending packets the wrong way, you'll have to teach it how to
| send them the right way intead.
Dynamically, maybe? Patch IPPORTFW to add a route for the connecting
host, and patch IPMASQ to remove it again when the masq entry is
deleted? Wonder what that would do to performance...
|...
- Fred Viles <mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
