Hi,

thanks for the suggestions.

On 17 Jun 2001, at 2:59, David Maxwell wrote:
> First, make sure that none of the machines that will have two IPs (one
> public, from your SDSL block, one private from your NAT block) route
> (or sourceroute) between the two networks.

That is clear.

> Second, You cannot protect yourself from certain abuse by your SDSL
> provider in this config - since the workstation must accept packets on
> a single network card, if malicious external party 'A' can manage to
> send some packets to your ethernet Mac, with the correct destination
> IP, you will accept them. This should generally be possible only by
> someone on the same ethernet segment though, or someone who can
> reconfigure a server/router on your segment. This includes your SDL
> ISP in your config - a risk you'll have to evaluate for yourself.

I thought you had to have a direct connection to the switch to do 
this. From the outside only the SDSL router has such (and should 
be configured to allow mentainence access only from the inside or 
serial port). 

> Third, you don't have a traditional firewall with this config - since
> you have lots of machines out in the open, with nothing in front of
> them - even if they're all NetBSD systems with good security
> capabilities, you're giving yourself a lot more opportunities to make
> mistakes.

Allthough this is not planned I could put a firewall machine between 
the SDSL router and the switch.

Personally I think this is an ugly construction. The reason to do this 
is money: the customer is a small ISP and the cable connection is 
cheap with unlimited transfer volume and far away of being called 
reliable, while the SDSL connection is extremely reliable but cost 
twice as much per month and some traffic will cost up to USD 
0,40/MB. Some of his customers tend to send dozends of e-mail 
messages with a few MB each per day.

So the idea is to have an internal connection and a NFS server 
where the e-mail messages are stored, in case the cable 
connection is down, one of the SDSL machines is the higher MX in 
his DNS config and stores incomming messages in the same places 
the cable machine would. This machine was configured as a pop 
server too, if the cable outage is longer, his customers could use 
the alternate pop server.The same way his www servers were 
configured so that when a longer outage on the cable connection 
occurs, only some IP switching in his DNS was neccessary to keep 
things going again.

I tried to convince him to entirely drop the cable connection, but 
money ...

Thanks

mike