Subject: Re: is this a job for ipnat?
To: None <tech-net@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-net
Date: 12/05/1999 05:17:26
>>> rdr ppp0 132.206.78.38/32 port=23 -> 132.206.78.1 port=7575 tcp
>> I really don't want anything stateful; [...]
> 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.

Well, yeah, that's what I want it to do: incoming packets addressed to
132.206.78.38.23 get rewritten as addressed to 132.206.78.1.57575;
outgoing packets from 132.206.78.1.57575 get rewritten as being from
132.206.78.38.23, otherwise untouched.  That's what I had with the
serial netlink I'm replacing....

> 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.

I'm doing nothing else with ipnat on this box at all, so I guess I
won't have any map rules if I don't need them for this. :-)

> (dual rdr rules won't work because the ports in the rule refer to
> destination ports, not source.)

Oh.  Foo.

Looks as though I'll have to special-case it in the kernel, since (if
I've understood you correctly) ipnat can't match packets based on
ip_src and tcp_sport, and can't rewrite tcp packets without insisting
on keeping state about connections-in-progress.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B