[EMAIL PROTECTED]">OK, I'm prepared to be knocked down in flames here (only if your gentle), but recently I paid a reasonably well known Linux consultant to advise me on a job I'm doing for a paying customer to install a firewall (that has to do masquerading of all well known services). His/her sugestion was to stick with ipchains for the time being (preferably under 2.2 kernel because the helper modules were already written and known to work) After some of my own research, I came up with the following from the man (rusty) himself:On Tue, 5 Mar 2002, Andy Eager wrote:Certainly pretty good as far as a basic explanation goes, problem is
that masquerading is not yet up to the level of ipchains and thats what
most people want. (One IP address, masqueraded to many machines for use
with ftp, realaudio etc). I still reckon that ipchains with a 2.2
kernel is still the simplest and most generally accepted way to do
firewalling if you want particular services masqueraded.
I'm interested to know your reasoning here.
494: <sect2>Altering the Destination of Locally-Generated Connections
495:
1.15 rusty 496: <p>The NAT code allows you to insert DNAT rules in the OUTPUT chain,
497: but this is not fully supported in 2.4 (it can be, but it requires a
498: new configuration option, some testing, and a fair bit of coding, so
499: unless someone contracts Rusty to write it, I wouldn't expect it
500: soon).
501:
502: <p>The current limitation is that you can only change the destination
1.16 rusty 503: to the local machine (e.g. `j DNAT --to 127.0.0.1'), not to any other
1.15 rusty 504: machine, otherwise the replies won't be translated correctly.
1.1 rusty 505:
506: <sect>Special Protocols
507:
508: <p>Some protocols do not like being NAT'ed. For each of these
509: protocols, two extensions must be written; one for the connection
510: tracking of the protocol, and one for the actual NAT.
511:
512: <p>Inside the netfilter distribution, there are currently modules for
513: ftp: ip_conntrack_ftp.o and ip_nat_ftp.o. If you insmod these into
514: your kernel (or you compile them in permanently), then doing any kind
515: of NAT on ftp connections should work. If you don't, then you can
516: only use passive ftp, and even that might not work reliably if you're
517: doing more than simple Source NAT.
[EMAIL PROTECTED]">Are you masquerading all of these (both passive & active ftp?). I would be keen to hear that there _are_ conntrack modules for the other protocols you mentioned.
What, exactly, doesn't work under iptables?
I have a 2.4 kernel running iptables, and it seems to do everything fine -
telnet, ssh, ftp, ICQ, irc, real audio, http, https - I haven't found
anything yet that _doesn't_ work.
I am more than happy to learn, so please don't hammer me with lots of hurtful flames if I've missunderstood something here.
(I'm basically a very sensitive person on the inside!! make love not war!!)
[EMAIL PROTECTED]">
So, what am I missing?
DaZZa
