|On Thu, 20 Jun 2002 10:48:01 +0100 |Antony Stone <[EMAIL PROTECTED]> wrote | about Re: Completely NAT an ISP: A practical possibility?:
>> On Tuesday 18 June 2002 11:50 pm, Ramin Alidousti wrote: > > > On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote: > > > > This would break lots of protocols. How would the clients put up with > > > > this broken functionality? > > > > > > Good observation. Yes it breaks some (all not NAT-able), and when this is > > > used clients have to live up with the limitations. But as I said, for the > > > time being this is used to accomodate a multiple-ISP cenario where > > > clients need basically HTTP, FTP, and less percentage of H.323. > > > > Just a small note. FTP is one of the protocols that would break... > > This is, of course, assuming that they only do "simple NAT", rather than > implementing netfilter + associated helper modules inside the ISP.... > Thank you Antony. Indeed we were discussing different things! I believe now that Ramin made reference that protocols would break due to a lack of "connection conntracking" withou which packets couldn't suffer NAT properly. We have implemented a rudimentar NAT+conntrack kernel 2.2 patch, because by the time we netfilter/iptables was not available in all its glory ;o). What we did was to use a priority queue and hashtables to implement full NAT to FTP and H.323 only (our immediate needs by then). We've upgraded the solution to use netfilter/iptables last year. regards, Senra -- Rodrigo Senra MSc Computer Engineer (GPr Sistemas Ltda) [EMAIL PROTECTED] http://www.ic.unicamp.br/~921234 (LinUxer 217.243) (ICQ 114477550)
