On Tuesday, September 18, 2007 at 02:59:06 -0400, [EMAIL PROTECTED] wrote:
>Here is how it works.
>
>Router public IP is 9.9.9.9
>
>Ntp server IP is 10.10.10.10
>
>Client IP is 16.16.16.16
>
>1) Client sends packet from 16.16.16.16#58000 to 9.9.9.9#123
>
>2) Router receives packet on 9.9.9.9#123
>
>3) Router forwards packet to 10.10.10.10#123 WITHOUT changing ANYTHING in
>the IP headers.
As mentioned by Jan, that's not gonna work. If you want to forward the
packet, you need to change the IP address or the NTP server will ignore
the packet. You might be able to fix this with a lot of trickery, but
that's not the way normal port forwarding works.
>4) NTP server on 10.10.10.10#123 sees and incoming packet from
>16.16.16.16#58000 and it just normally replies to it using its default
>route.
>
>5) Router only swaps IP 10.10.10.10 for 9.9.9.9 in the IP header without
>changing to source port.
I'm not so sure this is possible with most SOHO equipment. Surely it
can be done on with Linux, OpenBSD, IOS and similar software, but in
those cases running out of states usually isn't an issue [1].
>6) Client (16.16.16.16) receive reply packet from 9.9.9.9#123 on port
>58000
BTW: at least in OpenBSD's pf, it's much more efficient to match state
than to match a filtering rule. So if you want to keep the latency down
to a minimum, you do want to keep state.
Maurice
[1] I saw about 8000 states last week during one of the spikes [2], but
it didn't seem to hurt. And that was on a Soekris 4501, with a 486
class processor and 64 MB memory, running OpenBSD.
[2] Those spikes seem to be gone, thanks to the new DNS system.
Great job!
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
