However, maybe you could briefly explain what this change in the Endpoint filtering means and if there are any security considerations with it.
Hi swehjo,
your question is aimed at the so called "filtering behaviour" of a NAT (another question is the so called "mapping behaviour" of a NAT which must not be confused with its filtering behaviour, although the same or similar sounding terms "Enpoint-Independent", "Address-Dependent " and "Address- and Port-Dependent" are used to distinguish between the three possible mapping types).
What D-Link calls "restricted" is officially called "dependent". For UDP protocol you'll find a perfect explanation of the three terms "Endpoint-Independent Filtering", "Address-Dependent Filtering" and "Address and Port-Dependent Filtering" in
Section 5 of
RFC4787. For TCP protocol it's almost the same with a minor difference, details can be found in
Section 4.3 of
RFC5382.
In general, if you establish an outgoing UDP or TCP NAT session, the filtering behaviour of a NAT tells to what extent it is allowed to reuse the external address and port that is tied to the NAT session for another connection that is initiated from outside and targeted to your internal endpoint of the NAT session. In general you only want to allow traffic coming from the external destination address and port your outgoing NAT session was directed to (this is "Address and Port-Dependent Filtering" which is the most secure filtering mode). If you want to allow return traffic initiated from the same external destination address but coming from a different port, you can do this by configuring "Address-Dependent Filtering". And if you want to allow return traffic initiated from anywhere (any external host), you have to configure "Endpoint-Independent Filtering". This may be necessary in some cases to get peer to peer based applications (often: games) to work and it is the least secure filtering mode, because your NAT is quite open to the Internet (if I knew the external address and port of your alive NAT session I could try to start a connection to your PC that initiated the NAT session, at least your NAT router will not prevent me from doing so, because it allows it while operating in "Endpoint-Independent Filtering" mode).
PT
Edit: As I guess from the descripton how ReadyNAS works (see
here), ReadyNAS server and client both seem to establish outgoing connections to some kind of rendezvous server operated by someone (Netgear?) somewhere in the Internet. Otherwise ReadNAS' use wouldn't be that easy to configure without the need to modify any NAT router's configuration. It is the job of that rendezvous server to push data arriving from the connection to the ReadyNAS client into the connection established by the ReadyNAS server and vice versa. I guess while doing so the operator of that rendezvous server can see the data unencrypted, so I hope you trust him... (maybe that's the price you have to pay for simplicity of use). If it works like this, there should be no influence of changing the default filtering behaviour of your router, because there seems to be no need to allow "Endpoint-Independent Filtering" (or perhaps "Address restricted" in case of TCP) in order to get ReadyNAS to work.
Author
Topic: Blocked TCP packet with unexpected sequence (Read 17082 times)