Completely NAT an ISP: A practical possibility?

Completely NAT an ISP: A practical possibility?

[Brian Capouch]

I tried to capture the whole message there in the subject :-)

I wonder if the sages on this list might share advice as to whether or 
not it might be practical to maintain a working ISP where ALL client 
machines use private IP addresses, which are then NAT-ted to public IP 
space as necessary by iptables.

I am getting ready to deploy a small ISP, and this is a very attractive 
idea, but when soliciting ideas from various in-the-know folks I have 
consulted opinions seem to vary very widely.

The biggest drawback that has been voiced so far is that many 
peer-to-peer apps would break, but I'm not so sure right now that is bad 
thing.

All advice gratefully considered.

Thanks.

B.

Re: Completely NAT an ISP: A practical possibility?

[Antony Stone]

On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> I wonder if the sages on this list might share advice as to whether or
> not it might be practical to maintain a working ISP where ALL client
> machines use private IP addresses, which are then NAT-ted to public IP
> space as necessary by iptables.
>
> The biggest drawback that has been voiced so far is that many
> peer-to-peer apps would break, but I'm not so sure right now that is bad
> thing.

Some current ISPs already do this, and I guess the popularity with their 
customers varies according to what the customers want to do :-)

I know of 'residential' accounts where the ISP gives you a private address 
and you're dynamically NATted out to the Internet (so there's no possibility 
at all of hosting incoming services), and 'business' accounts where you have 
two-way static SNAT/DNAT, where as you say above some protocols will work and 
some won't.

Technically there's certainly no reason at all why you can't do this; in 
practice it'll come down to the contract you have with your customers, and 
what they can reasonably expect to be able to do with the connection you 
provide.

Just out of interest, how are you proposing to handle bandwidth allocation - 
making sure each customer gets a reasonable bandwidth without hogging the 
whole link ?

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Brian Capouch]

Antony Stone wrote:
> 
> Just out of interest, how are you proposing to handle bandwidth allocation - 
> making sure each customer gets a reasonable bandwidth without hogging the 
> whole link ?
> 

(Ducking) Still studying that matter, but the current 
candidates-of-record are tc, and cbq, but the Advanced Routing HOWTO is 
about to scare me off from CBQ, even though they admit there that it is 
the "most hyped."

I won't mind any advice in that arena, either :-)

Thx.

B.

Re: Completely NAT an ISP: A practical possibility?

[Nick Drage]

On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> > I wonder if the sages on this list might share advice as to whether or
> > not it might be practical to maintain a working ISP where ALL client
> > machines use private IP addresses, which are then NAT-ted to public IP
> > space as necessary by iptables.
> >
> > The biggest drawback that has been voiced so far is that many
> > peer-to-peer apps would break, but I'm not so sure right now that is bad
> > thing.
> 
> Some current ISPs already do this, and I guess the popularity with their 
> customers varies according to what the customers want to do :-)

Can you name any ISPs that do this?  I haven't seen it in my limited
experience.

<snip>

-- 
FunkyJesus System Administration Team

Re: Completely NAT an ISP: A practical possibility?

[Antony Stone]

On Sunday 16 June 2002 12:17 am, Nick Drage wrote:

> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> > > I wonder if the sages on this list might share advice as to whether or
> > > not it might be practical to maintain a working ISP where ALL client
> > > machines use private IP addresses, which are then NAT-ted to public IP
> > > space as necessary by iptables.

> > Some current ISPs already do this, and I guess the popularity with their
> > customers varies according to what the customers want to do :-)

> Can you name any ISPs that do this?  I haven't seen it in my limited
> experience.

There's a satellite ISP in the UK which does this - it's called either Hughes 
or StreamBeam, I'm not sure which is the end provider and which is the 
sub-carrier.   The equipment they provide is labelled Hughes.

As a standard account you get private (10.x.y.z) addresses on the end of the 
link, however you can ask for public-private NAT and they do SNAT/DNAT to 
your private addresses (one-to-one mapping).

I thought I'd heard that some ADSL services in UK provide private addresses 
too, but I've never had this, so I can't comment from personal experience.

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Sathi]

Hi,
I am Sathi from India.
I have implemented this in my place by providing a connectionn to 100 to 150
customers.

I provide a Local ip address and all will be terminate in a linux box in my
office which is then nated to public ip.

Everything looks fine except MSN voice chat , NETMEETING voice and video and
some other tools used for phone2pc and pc2phone.

Regards,
Sathi

> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:
>
> > > I wonder if the sages on this list might share advice as to whether or
> > > not it might be practical to maintain a working ISP where ALL client
> > > machines use private IP addresses, which are then NAT-ted to public IP
> > > space as necessary by iptables.
> > >
> > > The biggest drawback that has been voiced so far is that many
> > > peer-to-peer apps would break, but I'm not so sure right now that is
bad
> > > thing.
> >
> > Some current ISPs already do this, and I guess the popularity with their
> > customers varies according to what the customers want to do :-)
>
> Can you name any ISPs that do this?  I haven't seen it in my limited
> experience.
>
> <snip>
>
> --
> FunkyJesus System Administration Team
>
>

nat problem.

[umar]

Hi, 
 
Trying out  a very simple configuration of a firewall here, but having some problems.
The firewall  has two NIC's and have enabled ip forwarding. 

I want the internal machines to connect to the internet,  So have enabled NAT : 
Runing squid - transparent proxy on port 3232. Clients have been onfigured to connect to internet directly. 
eth0 is my external interface.
 
Following are the nat rules conigured on the firewall
 
iptables -t nat -A PREROUTING -i eth0  -p tcp --dport 80 -j REDIRECT --to-port 3232
 
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x ( public IP of the other netwrok card )

I can ping to the gateway ( private IP ) and the other network card havng the public IP , but nothing beyond that, Why ?? 
And my clients are also not able to connect to the internet ?? 
I have tried removing the first rule and disabling squid, so that clients could connect to the intenet directly. 
That also failed, and the result is the same. All the default poilicies of all rules are set to ACCEPT.

Runing rh 7.2 with 2.4.7-10 kernel.

Please help. 

Warm Regards, 
Kumar. 

(no subject)

[skmail]

Hi all-

I'm trying to patch a stock 2.4.18 kernel with a few extras from the
current patch-o-matic.  The only one that seems to have trouble so far
(kernel compile in progress) is the string match support.  Here is the
output of my kernel compile.  Can somebody help?  TIA

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_limit  -c -o ipt_limit.o ipt_limit.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   -DKBUILD_BASENAME=ipt_mac  
-c -o ipt_mac.o ipt_mac.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_multiport  -c -o ipt_multiport.o ipt_multiport.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_time  -c -o ipt_time.o ipt_time.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_state  -c -o ipt_state.o ipt_state.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_iplimit  -c -o ipt_iplimit.o ipt_iplimit.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_unclean  -c -o ipt_unclean.o ipt_unclean.c
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes 
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common 
-pipe -mpreferred-stack-boundary=2 -march=i486   
-DKBUILD_BASENAME=ipt_string  -c -o ipt_string.o ipt_string.c
ipt_string.c:80:72: macro "max" passed 3 arguments, but takes just 2
ipt_string.c: In function `search_sublinear':
ipt_string.c:53: warning: subscript has type `char'
ipt_string.c:78: warning: subscript has type `char'
ipt_string.c:80: `max' undeclared (first use in this function)
ipt_string.c:80: (Each undeclared identifier is reported only once
ipt_string.c:80: for each function it appears in.)
make[3]: *** [ipt_string.o] Error 1
make[3]: Leaving directory `/usr/src/linux/net/ipv4/netfilter'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/net/ipv4/netfilter'
make[1]: *** [_subdir_ipv4/netfilter] Error 2
make[1]: Leaving directory `/usr/src/linux/net'
make: *** [_dir_net] Error 2

Re: nat problem.

[Antony Stone]

On Monday 17 June 2002 11:58 am, umar wrote:

> Hi, 
>  
> Trying out  a very simple configuration of a firewall here, but having some
> problems.
 The firewall  has two NIC's and have enabled ip forwarding.
> 
> I want the internal machines to connect to the internet,  So have enabled
> NAT : 
 Runing squid - transparent proxy on port 3232. Clients have been
> onfigured to connect to internet directly. eth0 is my external interface.
>  
> Following are the nat rules conigured on the firewall
>  
> iptables -t nat -A PREROUTING -i eth0  -p tcp --dport 80 -j REDIRECT
> --to-port 3232
 
> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x ( public
> IP of the other netwrok card )
 

What do you mean "IP of the *other* network card" ?

The address here should be the address of eth0.   Tell us if you're using 
something else, and if so what you're using (we don'tneed to know the IP 
address, just where it lives on the network).

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Sun, 16 Jun 2002 00:17:45 +0100
|Nick Drage <nickd@funkyjesus.org> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

>> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:
> 
> > Some current ISPs already do this, and I guess the popularity with their 
> > customers varies according to what the customers want to do :-)
> 
> Can you name any ISPs that do this?  I haven't seen it in my limited
> experience.
> 

 Here in Brazil this is often used, though I'm not at liberty to name actual
 ISPs. We have very little H.323 (read Netmeeting) demand, but it is growing.
 Most ISP clients still have 56Kbps dial-up access, with the number of ADSL
 clients increasing fast. 

 The NAT solution is often used to allow multiple ISP access though the 
 same media provider (probably ADSL). Since there is a law that a 
 "Content Provider" (like aol,etc) cannot be same as the media provider
 (like AT&T, etc), which fosters the adoption solution such as that. 

 In fact, it is not the ISP that is "Natted", but a subset of the client address
 space before they reach their target ISP, and while in transit in the media
 provider routers. Naturally, there is some cooking to achieve that. 

 I'm not sure if this is the kind of practical appication youe were expecting to hear
 from, but there is no harm to talk about it anyway....

 regards,
 Senra
   
-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

On Tue, Jun 18, 2002 at 02:16:32PM -0300, Rodrigo Senra wrote:

> |On Sun, 16 Jun 2002 00:17:45 +0100
> |Nick Drage <nickd@funkyjesus.org> wrote
> | about Re: Completely NAT an ISP: A practical possibility?:
> 
> >> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:
> > 
> > > Some current ISPs already do this, and I guess the popularity with their 
> > > customers varies according to what the customers want to do :-)
> > 
> > Can you name any ISPs that do this?  I haven't seen it in my limited
> > experience.
> > 
> 
>  Here in Brazil this is often used, though I'm not at liberty to name actual
>  ISPs. We have very little H.323 (read Netmeeting) demand, but it is growing.
>  Most ISP clients still have 56Kbps dial-up access, with the number of ADSL
>  clients increasing fast. 
> 
>  The NAT solution is often used to allow multiple ISP access though the 
>  same media provider (probably ADSL).

Doesn't bridged context DSLAM eliminate the need for the NAT?


>   Since there is a law that a 
>  "Content Provider" (like aol,etc) cannot be same as the media provider
>  (like AT&T, etc), which fosters the adoption solution such as that. 
> 
>  In fact, it is not the ISP that is "Natted", but a subset of the client address
>  space before they reach their target ISP, and while in transit in the media
>  provider routers. Naturally, there is some cooking to achieve that. 

This would break lots of protocols. How would the clients put up with
this broken functionality? Or maybe they tunnel on top of this IP network
which is still a huge overhead...and needs additional client-side config.

Ramin

> 
>  I'm not sure if this is the kind of practical appication youe were expecting to hear
>  from, but there is no harm to talk about it anyway....
> 
>  regards,
>  Senra
>    
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Tue, 18 Jun 2002 14:50:05 -0400
|Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

> >  The NAT solution is often used to allow multiple ISP access though the 
> >  same media provider (probably ADSL).
> 
> Doesn't bridged context DSLAM eliminate the need for the NAT?

I humbly confess that I do not know what DSLAM is ;o)

> 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.  

Take notice that NAT takes place before the packets reach their service providers.
So maybe, I couldn't call it properly  "NAT an ISP" as the title suggests.
 
> Or maybe they tunnel on top of this IP network

Not that I know of.
Thank you for your observations.

regards,
Senra
-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

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...

Ramin

> 
> Take notice that NAT takes place before the packets reach their service providers.
> So maybe, I couldn't call it properly  "NAT an ISP" as the title suggests.
>  
> > Or maybe they tunnel on top of this IP network
> 
> Not that I know of.
> Thank you for your observations.
> 
> regards,
> Senra
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Tue, 18 Jun 2002 18:50:58 -0400
|Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

 >> On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote:
> 
> 
> Just a small note. FTP is one of the protocols that would break...

Hi,
  could you care to explain me how it would break ? Since it is working
  here ;o), I think we are discussing different scenarios because of my
  poor explanation on the matter.

 But I think I can gain a lot from your explanation.

 TIA,
 Senra 
-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

On Wed, Jun 19, 2002 at 11:36:33AM -0300, Rodrigo Senra wrote:

> |On Tue, 18 Jun 2002 18:50:58 -0400
> |Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
> | about Re: Completely NAT an ISP: A practical possibility?:
> 
>  >> On Tue, Jun 18, 2002 at 05:22:03PM -0300, Rodrigo Senra wrote:
> > 
> > 
> > Just a small note. FTP is one of the protocols that would break...
> 
> Hi,
>   could you care to explain me how it would break ? Since it is working
>   here ;o), I think we are discussing different scenarios

I defer this explanation to the documents available about the NAT
and FTP. You can start with the netfilter documents on the need
for ip_nat_ftp. Also the FTP protocol and more specifically the
PORT command would give you what you're looking for.

>   because of my poor explanation on the matter.

No, not at all.

Ramin

> 
>  But I think I can gain a lot from your explanation.
> 
>  TIA,
>  Senra 
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Antony Stone]

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....

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Thu, 20 Jun 2002 10:48:01 +0100
|Antony Stone <Antony@Soft-Solutions.co.uk> 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)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Ramin Alidousti]

On Thu, Jun 20, 2002 at 04:37:10PM -0300, Rodrigo Senra wrote:

> > > > 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).

Oh, I see, I wasn't thinking in terms of netfilter when I read your
original email about NATting FTP. Yes, FTP is supported and (although
I didn't do it myself) H.323 is also supported (except for certain
functionalities, I hear). So, you can easily say that your routed
context DSL solution works by means of a linux nat box.

Do you guys do DNAT too? I mean do you let the costomers run services?
Who assigns IP's to them? The content providers? How do you sync up
with them for the DNAT? The whole NAT solution between the medium provider
and the content provider is still a bit vague to me, especially when you
sell static IP's to the customers...

> 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).

Feel free to elaborate on this priority queue/hashtables implementation
to solve FTP/H.323 problem. Sounds like an extendable thing for other
unfriendly protocols.

> We've upgraded the solution to use netfilter/iptables last year.

Good for you.

Ramin

> regards,
> Senra 
> 
> -- 
> Rodrigo Senra         
> MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
> http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Re: Completely NAT an ISP: A practical possibility?

[Rodrigo Senra]

|On Thu, 20 Jun 2002 20:19:43 -0400
|Ramin Alidousti <ramin@cannon.eng.us.uu.net> wrote
| about Re: Completely NAT an ISP: A practical possibility?:

> Do you guys do DNAT too? I mean do you let the costomers run services?

Nope. Only SNAT is used to route the client pool (with the same media provider)
to the appropriate ISP.

> Who assigns IP's to them?

They used DHCP with ADSL ( I said there were some dial-ups but I was mistaken, all use ADSL now)

> The content providers? How do you sync up with them for the DNAT?

They sync up for SNAT. They have to authenticate via Web (before the firewall/router to ISP),
after that a some rules are added automagically to the firewall by a third interface.
Since all use ADSL accounting can be done by crossing (ADSL modem ID,Dynamic IP, time, logs).

              /------- Web Auth-v
client pool -                   | 
              \ ----- Firewall/Router----------(ISP pool)
                                   \------------  "
                                   \------------- "

> The whole NAT solution between the medium provider
> and the content provider is still a bit vague to me, especially when you
> sell static IP's to the customers...

In fact there are no more static addresses, I mixed up some scenarios in my
previous e-mails ;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).
> 
> Feel free to elaborate on this priority queue/hashtables implementation
> to solve FTP/H.323 problem. Sounds like an extendable thing for other
> unfriendly protocols.

We dropped that solution because it was focused in kernel 2.2 and iproute2.
Basically we had a priority queue acting as a self-made conntrack module.
We have chosen in favour of a priority queue "statistically"
betting in better performance, supposing client traffic would be in bursts
during short periods of time. That proved to be  more efficient than using a hashtable 
as the top level indexing structure.

I do not know in what data structures the current conntrack/filtering is based, 
did not have the time (and the need!) to check it out. For the time being I trust
is is fast/smart enough. If it becomes a bottleneck, then we'll see !

best regards
Senra     

-- 
Rodrigo Senra         
MSc Computer Engineer   (GPr Sistemas Ltda)     rodsenra@gpr.com.br 
http://www.ic.unicamp.br/~921234  (LinUxer 217.243) (ICQ 114477550)

Completely NAT an ISP: A practical possibility?

[hard__ware]

Completely NAT an ISP: A practical possibility?


>Antony Stone wrote:

> > Just out of interest, how are you proposing to handle bandwidth
allocation -
> > making sure each customer gets a reasonable bandwidth without hogging
the
> >whole link ?


>(Ducking) Still studying that matter, but the current
>candidates-of-record are tc, and cbq, but the Advanced Routing HOWTO is
>about to scare me off from CBQ, even though they admit there that it is
>the "most hyped."
>
>I won't mind any advice in that arena, either :-)
>
>Thx.


A CBQ and a few SFQ limits will do this perfectly
as you can match by IP / Protocol / Headers / (Actual Data Contained inside
of each Packet / Frame )
and ToS fw Marks .. :D

And about the NAT / ISP thing , i think it would be great to do someting
like that .. :D
i so hate peer-to-peer sharing over the internet ... lol

what kind of ISP is it going to be dialup , ISDN ??

because Radius & Portslave (Linux Dialin Server) will allow you to restict
Bandwidth per client ...
let me know how you go, as i have a Buisness Partner that plans to build a
NAT / IPTables ISP
so we can give these Buisness Based Clients exactlly what they want .. :D

  hope this helps

    Alex...

Hard__warE