On Sun, Dec 05, 1999 at 02:19:37AM -0500, der Mouse wrote:
> >> [...packet-rewriting want...]
> > rdr ppp0 132.206.78.38/32 port=23 -> 132.206.78.1 port=7575 tcp
> Oh, ick.  I really don't want anything stateful; these connections
> sometimes sit idle for long periods, and I don't want one to get killed
> because the gateway box got rebooted.
> 
> It sounds as though ipnat does too much - I want its packet matching
> and rewriting engine but not the rest of it.  Is there some way to tell
> it "don't keep state, just rewrite the packets"?  I can easily enough
> put rdr lines on both le0 and encap0 to rewrite packets in both
> directions, if that's what it takes.
	Well you really need the statefullness of it, unless you change it
it to also look at the source address of the packets from the inside
and keep the packets from getting adjusted by any "map" rules.  If you don't
have any map rules then you should be fine, but if you do then any outgoing
packets from the target port of the redirection will get assigned a different
source port by the "map" rules instead of getting translated into the correct
original redirected port and trigger a reset from the other end.  (assuming
there isn't an entry in the active sessions for the original rdr action)
	In other words, allow the rdr active session entry to be setup from
either side.  This almost sounds like a fairly useful extension to add
to the ipnat config grammar.  Perhaps something like
"rdr-2way ep0 ..." or "rdr ep0 ... 2-way"?
	(rdr already works fine as long as the originating end sends the 
first packet after the gateway machine reboots or otherwise has its 
active session listing flushed.)
	(dual rdr rules won't work because the ports in the rule refer
to destination ports, not source.)
	Or perhaps make this behavior the default?  What programs originate
connections from the same address on which they listen to (and to which
a port might be redirected to)?  hmm... using the 2-way option would make it 
impossible to open a connection with the target port of a redirection as
a source port; so maybe it shouldn't be a default, but it seems useful
enough to add as an option.

eric