Thanks for demonstrating how, in theory, a NAT router can avoid keeping state for NTP packets if there's manual port forwarding.

In practice, are cheap consumer routers smart enough to not maintain state? I'm worried about things like the Linksys WRT54G with stock firmware. And I'm guessing they're not.

[EMAIL PROTECTED] wrote:
On Tue, 18 Sep 2007, Maurice Janssen 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.

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.

6) Client (16.16.16.16) receive reply packet from 9.9.9.9#123 on port 58000

No masquerading or state needed, it is just simple basic NAT where the router :

1) Just forward the packet to the NTP server without changing anything in the headers.

2) On the reply, swap the internal IP for its external IP.

This worked way before masquerading was implemented, it is simple 1 to 1 port mapping.

-ls




On Monday, September 17, 2007 at 21:58:44 +0200, Jan Hoevers wrote:
I see little harm in a stateless NAT setup, no tables to overflow, just
If your router does a translation but doesn't keep state, then how do
you make sure the port numbers of the reply match the port numbers of
the query?

For example: you get a query from IP 1.2.3.4 port 1234 to your router's
external IP of 8.7.6.5 on port 123.  This translates to 10.0.0.1 port
123.  So far, so good.
The reply from your server has destination 1.2.3.4 port 1234 and source
10.0.0.1  port 123.  Your router needs to translate the source address
and will probably also translate the source port, in case there is no
state.
End result: the client ignores the reply, because the source port
doesn't match with query it had sent.

You might get away with it, if you can prevent the source port of the
reply packet from being translated.

Maurice

_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers


Louis
http://blogtech.oc9.com
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to