On Sun, 2002-05-05 at 22:30, Andrew Basterfield wrote: > Linux 2.4 will masquerade active ftp? How does it work then? It's a osi layer 7 filter - it pulls the ip and port information out of the ftp connection itself. Even 2.2 is able to masq active ftp. I don't believe the 2.2 implementation was ever _really_ good, but it worked in most common circumstances. The hard part is re-writing the data stream: if the client tells the server to PORT 10,0,0,1,2000 you need to rewrite that to the external interface of the gateway (let's say, for example, 200.200.200.200.31929) - this string is much longer than the other one, so not only have you got to re-write that in place, but you then have to juggle the lengths of the packets and the sequence numbers. You also have to do this both ways, so that the server makes sense to the client. Not pretty, but then, that is why ftp is so hard to masquerade well. > > My point was that blocking on various rules isn't nearly as good as not > > actually having the packet routing available - given a source > > nat/masquerading setup, and a 1-1 private:public nat setup, the > > masquerading system is more protective because to route to a private > > machine requires an entry in the de-masquerade machinery. > > You can have both, they're not mutually exclusive. You can have both a source nat and 1-1 nat setup? You might want to re-read that ;) > the inside to the outside. NAT was designed to help reduce the pressure on > the depleted free IP address space, Well, the real worry was also actually maintaining the list of backbone routing tables - more networks means longer routing tables. IPv6 fixes this quite nicely, as you obviously already know. I agree with you about the obsolence of masquerading though, it should all be done through proxies really. I'm not sure nat itself will ever go away, but there become fewer compelling reasons to use it once you go to IPv6. Cheers, Alex.
Attachment:
signature.asc
Description: This is a digitally signed message part