Re: NAT (Was: Is source address selection based on rules (netfilter) possible ?)

Pascal Hambourg a écrit :
You cannot rely on it. Due to the lack of standardization, there are
many different implementations of NAT.

But at least NAT put you "behind" an opaque wall, for incoming traffic. Ie. portcan or direct attacks from the outside won't be possible, at least.

Of course, it means that legit servers will also have really big troubles (including crazy standard such as H323)
.

Relevant Pages

  • Re: Just want to keep the crap out!!
    ... It looks to me like the simpler the NAT device the better. ... implementations don't have any connection tracking modules or only ... I've read such stupid advice way to often. ... Internet connection is better than directly connecting a Windows box to ...
    (comp.security.firewalls)
  • Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess)
    ... >>Oh, yeah, I know of UDP or TCP encapsulation tricks that work. ... >>dealt with several of these implementations too. ... One can indeed have multiple internal VPN devices ... > tricks to work around NAT. ...
    (freebsd-isp)
  • Re: IPSec VPN & NATD (problem with alias_address vs redirect_addr ess)
    ... >>Oh, yeah, I know of UDP or TCP encapsulation tricks that work. ... >>dealt with several of these implementations too. ... One can indeed have multiple internal VPN devices ... > tricks to work around NAT. ...
    (freebsd-net)
  • Re: Just want to keep the crap out!!
    ... I guess we should distinguish between the concept of NAT and particular implementations. ... It should never assign a source port corresponding to an unrelated service. ... defective NAT implementations are as good as a direct connection. ...
    (comp.security.firewalls)
  • Re: Just want to keep the crap out!!
    ... hardware NAT. ... even a defect. ... defective NAT implementations are as good as a direct connection. ... vulnerabilities where no patch and, in some cases not even a workaround ...
    (comp.security.firewalls)