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