On 11/12/13 10:13 am, "Alex White-Robinson" <alexwr@gmail.com> wrote:
Wotcha,
Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) since you have to treat each boxes as if it was public.
I see this kind of statement surprisingly often. Having a public address doesn't make a device public.
Yes it does, it makes end to end connectivity work again. NAT broke that (and its one of the best things about v6). People have been relying on the fact that you need rules to get through a NAT to reach a box - thereby having NAT work as an inbound firewall. NAT != Security. But yes having a public address means your box is public, you have to do something to STOP traffic getting to it. With NAT you have to do something to ENABLE traffic to get to it.
I don't really see a drive to have devices exposed to the internet without a stateful device in front of them in IPv6 world. People shouldn't allow unsolicited connections to hit your internal workstation on any address scheme.
Cheers, Alex.
Date: Tue, 10 Dec 2013 05:56:41 +1300 From: Pieter De Wit <pieter@insync.za.net> To: nznog@list.waikato.ac.nz Subject: Re: [nznog] Web Servers: Dual-homing or DNAT/Port Forwarding? Message-ID: <52A5F649.7070904@insync.za.net> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hi,
I normally use a combination of "1" and "2". I prefer 1 for weird and "not nat friendly" protocols, like SIP or some other application. The general rule of thumb is to use number 2 in other cases. In both setups, remember to deploy local firewalls as well. This will help for the case when a box on the subnet is hacked.
My other twist is to deploy "1" without the private NIC, along with local firewalls (and as you said, dedicated FW).
Number 1 gets you thinking along the IPv6 route (no pun, and imho :) ) since you have to treat each boxes as if it was public.
Cheers,
Pieter