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