:: Re: [DNG] IPv6 for dummies by a dum…
Forside
Slet denne besked
Besvar denne besked
Skribent: Simon
Dato:  
Til: Devuan ML
Emne: Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
o1bigtenor via Dng <dng@???> wrote:

> I hope that others might also contribute even questions and thereby
> a document in the 'how to' class is created.


In many ways that’s a better way - there’s only so much generic stuff you can throw at someone before they get overwhelmed. If anyone does have specific question then I’ll try and help.

>> You will want to configure an IPv6 firewall. I used Shorewall for this - it’s an amazing package. It’s still usable, but it’s time is now limited as it’s deeply entangled with iptables which is now deprecated and replaced with nftables. I imagine that at some point the iptables compatibility shim will go away and that will stop Shorewall.
>>
> I am looking at (have the hardware waiting for pickup) running something
> like Pfsense or Opnsense for a firewall. It seems that either support
> ipv6 as well.


I would imagine either of those would do fine based on reputation - I’ve not used either.


> Wondering about physical setup.
>
> I had thought of running my network (part of it at least) like this:
>
> WAN == router == firewall == managed switch == complicated network
>
> It has been suggested to me that I should combine the router and
> the firewall functions into the same machine. Which option (combining
> functions or separating functions) gives a more robust network?


You can run it as you’ve drawn, but the firewall will inherently end up doing internal routing functions - effectively you’ve mane the router-firewall link there analogous to the ISP provided Wan link for your firewall.
To elaborate, assuming you end up with multiple networks, traffic between them will need to be routed and managed. What you don’t want to do (and it would be tricky to configure anyway) is to route traffic out to the router only for it to be sent back in - passing through the firewall twice. So internal inter-network traffic could pass through the firewall just once, coming in through on VLAN interface, and being passed out via another one.
In theory the single ethernet link between firewall and switch can be a bottleneck if there’s lots of traffic between networks, but I suspect few home networks will find that a problem, and you can always add extra ethernet ports (either as separate connection or aggregated as a bonded interface) for more bandwidth.

> Where would a pihole function in this scenario?


Pretty well anywhere it’s convenient !
All you need to do it to direct internal devices to use the Pihole for their DNS - and block outbound DNS queries from anything but your internal DNS service. As long as clients can reach it, it doesn’t matter where in the network you put it.
According to a comment I read on a different mailing list, you may have to redirect “unauthorised” network traffic with firewall rules - so that devices which use hardcoded external DNS servers can use your internal service.

> How secure can a system be made using firewall(s)?


Probably the only totally secure system is one that’s been shredded, the threads incinerated, and the resulting bits mixed into lumps of concrete which are dropped into the deepest trench in the ocean - but that’s not all that useful :D
If your firewall is reasonably secure in itself, then you can do a lot with a “block everything that’s not allowed” policy. There’s massive scope for tradeoffs between the effort you put into setting up and maintaining the system and the ease of using it. I suspect that for most of us, it’s not too hard to reach a point where the effort needed to break in puts you into “there are simpler ways for those sufficiently resourced to get at you”. Blocking individual sites gets a bit more tricky, especially these days when there can be so many sites sharing addresses - which change (with the various hosting proxy services). The Pihole does that at the DNS level, or you’d need to setup and use a proxy server - which only works for HTTPS sites if you are able to install your own root certificate on each client.


Obligatory XKCD https://xkcd.com/538/



Steve Litt <slitt@???> wrote:

> Very soon I'll build myself an OpenBSD/pf firewall/router. At that time
> I might set up something like the following:
>
>      11.22.33.44                    0.0/24    100.0/24
> INTERNET======SPECTRUM_MODEM_FW/ROUTER====BSD/PF======WIRED_LAN
>                \\
>                 \=====WIFI_ACCESS_POINT=====Laptops
>                  0.0/24                0.0/24

>
> The preceding leaves the Spectrum modem/firewall/router/wifi open to
> the 20005 attack, but that attack can't go anywhere easily. I'll try
> very hard to disable the Spectrum's wifi. The OpenBSD/pf will protect
> the wired network from packets initiated from the Internet or from the
> wifi laptops. I might leave ports 80 and 22 open to the laptops so they
> can get house websites or ssh in. Also, I'll need to have them receive
> DHCP from somewhere, and try to configure the DHCP to specific MAC
> addresses.


That’s one way of doing it, but can be quite inconvenient - depending on your use case.

Personally, I have the WiFi inside the network, and run multiple SSIDs so different stuff can go on different networks - including having a guest network with client isolation turned on. At the moment I have a few bits of the puzzle missing, but eventually (given time and cost constraints) it’s my intention to run multiple VLANs for better segregation.

For many people, having wireless laptops behave differently to wired systems would be “a problem”. Especially if you have services (printing, file shares) that use mdns to locate/use them.

The reality is that there is no “right” or “wrong” way to do it - just different sets of priorities that make different topologies “better” or “worse” for different people. It really a game of finding “best” for your personal set of requirements and priorities. As I said above you can make a system really really REALLY secure - but also of no practical use !


Simon