[tomato] Pi-hole als DNS server op meerdere LAN bridges

[Toet3r]

Hallo,

Ik heb een probleem waar ik niet uit kom met het instellen van mijn Raspberry Pi als DNS server op meerdere bridges/vlans op mijn router. Router is een Asus rt-ac68u met de laatste tomato firmware.

Momenteel heb ik onder basic->network 2 LAN bridges aangemaakt. Elk met eigen dhcp range.

code:

bridge   ip address    subnet
br0      192.168.1.1   255.255.255.0
br1      192.168.2.1   255.255.255.0

Op br0 zitten de wired clients in alsmede mijn wifi netwerk
Op br1 zit mijn gasten wifi

de vlans zijn als volgt ingesteld

code:

vlan vid    port1   port2   port3   port4   wan-port    bridge
1   1       x       x       x       x                   LAN(br0)
2   2                                       x           WAN
3   3                                                   LAN1(br1)

Tagged staat op alle poorten niet aangevinkt.
br0 en br1 zitten op een aparte vlan. Gasten kunnen hierdoor wel op internet maar niet bij bij mijn LAN.

Het is ingewikkeld geworden sinds ik mijn raspberry pi als DNS server ben gaan gebruiken.

Bij advanced->dhcp/dns heb ik bij dnsmasq configuration het volgende ingesteld.

dhcp-option=6,192.168.1.254

Hierdoor gebruiken alle dhcp clients mijn pi (192.168.1.254) als dns server ipv 192.168.1.1 (ip van router)

clients op gasten wifi in br1 proberen ook de DNS server van de pi te bereiken maar dat lukt niet omdat die in andere bridge en vlan zit. Het is de bedoeling dat ze bij de DNS server op de pi kunnen maar niet bij de rest van br0.

met vlan/iptables krijg ik het niet voor elkaar dat clients uit br1 verbinding kunnen maken met de DNS server op de pi in br0.

Heb op internet wel een aantal voorbeelden van iptables gevonden maar

code:

iptables -A INPUT -d 192.168.1.254 -p tcp --sport 53 --dport 53 -j ACCEPT
iptables -A INPUT -d 192.168.1.254 -p udp --sport 53 --dport 53 -j ACCEPT

ook met FORWARD ipv INPUT en met en zonder de -i br1 en -o br0 parameters werkt niet.

Ik doe iets fout of mis iets maar ik zie niet wat.

[Martin.Air]

Als je van bridge1 naar bridge0 wilt is er buiten de toegang in iptables ook een routering nodig. Je zou een statische route in kunnen stellen, of een automatische in kunnen stellen (zoals de redelijk simpele RIP bijvoorbeeld) om dit op te lossen.

Als je dan toch bezig bent zou je er bijvoorbeeld voor kunnen kiezen om wel vanaf LAN bij WIFI te mogen, maar niet andersom

[Toet3r]

Ik kom er echt niet uit. Heb zitten klooien met static routes en iptables maar tot nu toe noppes.
Ik ben dan ook niet heel goed thuis in dit soort netwerk configuratie.

[Mijzelf]

Hangt die pi direct aan de router? Dan kun je natuurlijk ook de gasten vlan beschikbaar maken voor de pi, zodat die op 2 vlans zijn ding kan doen.

[eric.1]

1. routes regelen van en naar de DNS-server
2. FW regels regelen van en naar de DNS server

De "--sport 53" in jouw regels is trouwens niet goed. Vanaf welke poort een request naar de DNS-server gestuurd wordt is niet relevant (en van tevoren vaak niet bekend).

P.S. zorg je ook voor de terugweg ?

[ Voor 27% gewijzigd door eric.1 op 23-07-2018 22:41 ]

[Toet3r]

Mijzelf schreef op maandag 23 juli 2018 @ 22:27:
Hangt die pi direct aan de router? Dan kun je natuurlijk ook de gasten vlan beschikbaar maken voor de pi, zodat die op 2 vlans zijn ding kan doen.

Ja zit op LAN2 poort op me router.

Untagged kan ik maar 1 vlan per port selecteren. Tagged kan je wel meerdere vlans per poort toewijzen.
Dit had ik al geprobeerdt maar dan werkte niks meer.
Zag net ook ergens dat ik br0 en br1 gewoon op 1 vlan kan zetten en dan met iptables de toegang instellen. Geen idee of dit makkelijker of beter is.

eric.1 schreef op maandag 23 juli 2018 @ 22:37:
1. routes regelen van en naar de DNS-server
2. FW regels regelen van en naar de DNS server

De "--sport 53" in jouw regels is trouwens niet goed. Vanaf welke poort een request naar de DNS-server gestuurd wordt is niet relevant (en van tevoren vaak niet bekend).

P.S. zorg je ook voor de terugweg ?

ok bedankt voor de tip, zal die sourceport eruit halen

[ Voor 62% gewijzigd door Toet3r op 24-07-2018 00:46 ]

[Martin.Air]

O stom sorry, routes zouden niet eens noodzakelijk zijn in dit geval. IP Forwarding moet aanstaan:

code:

echo 1 > /proc/sys/net/ipv4/ip_forward

Hierna zouden de IP table aanpassing enkel nodig zijn om toegang toe te staan. Ik zou beginnen met een regel die al het verkeer toestaat tussen de twee netwerken. Daarna kun je kiezen om al het andere verkeer bewust te blokkeren of de ik sta al het verkeer toe regel weer te verwijderen en opnieuw te proberen met specifieke regels.

[Frogmen]

Waarom zou je voor je gasten ook de raspberry pi voor DNS willen gebruiken ?

[Mijzelf]

Toet3r schreef op maandag 23 juli 2018 @ 22:58:
[...]

Ja zit op LAN2 poort op me router.

Untagged kan ik maar 1 vlan per port selecteren. Tagged kan je wel meerdere vlans per poort toewijzen.
Dit had ik al geprobeerdt maar dan werkte niks meer.

Je zou vlan 1 untagged aan moeten bieden, en vlan 3 tagged. Dan blijft alles gewoon werken, en vervolgens kun je op de pi vlan 3 kunnen afsplitsen naar een virtuele ethernet poort. Daarmee zit je pi in beide netwerken.

Je moet dan overigens wel in staat zijn om voor vlan3 een andere DNS te pushen, want natuurlijk heeft de pi in vlan3 een ander adres dan in vlan1

[Toet3r]

Martin.Air schreef op dinsdag 24 juli 2018 @ 08:42:
O stom sorry, routes zouden niet eens noodzakelijk zijn in dit geval. IP Forwarding moet aanstaan:

code:

echo 1 > /proc/sys/net/ipv4/ip_forward

Hierna zouden de IP table aanpassing enkel nodig zijn om toegang toe te staan. Ik zou beginnen met een regel die al het verkeer toestaat tussen de twee netwerken. Daarna kun je kiezen om al het andere verkeer bewust te blokkeren of de ik sta al het verkeer toe regel weer te verwijderen en opnieuw te proberen met specifieke regels.

Ook niet met de bridges elk in een aparte vlan?
In het voorbeeld zoals hier beschreven doet ie het alleen met iptables maar daar zitten de bridges wel in de zelfde vlan.

Frogmen schreef op dinsdag 24 juli 2018 @ 09:34:
Waarom zou je voor je gasten ook de raspberry pi voor DNS willen gebruiken ?

doordat in in dnsmasq dhcp-option=6,129.168.1.254 heb ingevuld proberen clients uit beide bridges die te gebruiken als dns server

[Martin.Air]

Toet3r schreef op dinsdag 24 juli 2018 @ 12:49:
[...]

Ook niet met de bridges elk in een aparte vlan?
In het voorbeeld zoals hier beschreven doet ie het alleen met iptables maar daar zitten de bridges wel in de zelfde vlan.


[...]


doordat in in dnsmasq dhcp-option=6,129.168.1.254 heb ingevuld proberen clients uit beide bridges die te gebruiken als dns server

Ah, nu zie ik ook pas dat het hier gaat om vlans enkel bedoeld om het gastnetwerk te creëren met Tomato binnen deze router. (Ben dit gesprek aangegaan met 0 kennis van Tomato, enkel kennis van netwerken)

Lets start over:

Jouw situatie zoals ik die zie:

code:

                        eth0, eth1, eth2, eth3 (Ethernet poorten van router)
                       /
             br0 -----
            /         \
wan0 ----             wl0, wl1 (Maar heten eth1 & eth2)
            \            
             br1 ----- wl0.1, wl1.1

Maar met die webpagina zou ik eigenlijk al denken dat

code:

echo 1 > /proc/sys/net/ipv4/ip_forward

al aan zou kunnen staan. Echter is dat niet helemaal duidelijk.

[ Voor 8% gewijzigd door Martin.Air op 24-07-2018 13:41 ]

[Toet3r]

Martin.Air schreef op dinsdag 24 juli 2018 @ 13:39:
[...]


Ah, nu zie ik ook pas dat het hier gaat om vlans enkel bedoeld om het gastnetwerk te creëren met Tomato binnen deze router. (Ben dit gesprek aangegaan met 0 kennis van Tomato, enkel kennis van netwerken)

Lets start over:

Jouw situatie zoals ik die zie:

code:

                        eth0, eth1, eth2, eth3 (Ethernet poorten van router)
                       /
             br0 -----
            /         \
wan0 ----             wl0, wl1 (Maar heten eth1 & eth2)
            \            
             br1 ----- wl0.1, wl1.1

Maar met die webpagina zou ik eigenlijk al denken dat

code:

echo 1 > /proc/sys/net/ipv4/ip_forward

al aan zou kunnen staan. Echter is dat niet helemaal duidelijk.

Ja sorry misschien was ik niet helemaal duidelijk.
Je overzicht klopt inderdaad.

vlan3 heb ik aangemaakt om me eigen wifi netwerk op br0 makkelijk te kunnen scheiden van gasten wifi op br1. Het kan ook op de zelfde vlan en dan scheiden met iptables.
Ik heb niet zoveel verstand van netwerken wat betreft wat de beste oplossing is.

[Martin.Air]

Toet3r schreef op dinsdag 24 juli 2018 @ 13:51:
[...]

vlan3 heb ik aangemaakt om me eigen wifi netwerk op br0 makkelijk te kunnen scheiden van gasten wifi op br1. Het kan ook op de zelfde vlan en dan scheiden met iptables.
Ik heb niet zoveel verstand van netwerken wat betreft wat de beste oplossing is.

Als ik het zo lees lijkt het niet uit te maken hoeveel/welke vlans je gebruikt. Vergeet ook niet dat een VLAN enkel een abstractie laagje op een verbinding is. Vandaar dat deze ook aangeduid worden met x.x nummers.

Misschien helpt het om je een voorstelling te maken van een bedrade aansluiting genaamd eth2, deze heeft untagged br0 en tagged (vlan 8 ) br1. Dan heb je virtueel eth2 en eth2.8.
Maar in werkelijkheid is het een aansluiting, een kabel. Aan de andere kant van die kabel kun je luisteren naar beide, of een van beide. Standaard luister je naar untagged, dus in dit geval br0.

Tomato lijkt dit principe te gebruiken om tussen de componenten te communiceren, dus tussen het interne deel van de router en het Wifi deel. Dat is de enige reden dat je een vlan aan moet maken, om aan het wifi deel mee te kunnen delen dat hij daar ook naar moet luisteren en wat mee moet.

Gelukkig maakt dit voor de situatie niet uit, het blijft dat jij zit met deze situatie (schets):

code:

                    br0 (192.168.1.1) ----- pihole (192.168.1.254)
                   /
 wan0 ----- router
                   \
                    br1(192.168.2.1) ----- client (192.168.2.x)

Dus je hebt 1 doel, kunnen communiceren van 192.168.2.x naar 192.168.1.254.

Hiervoor heb je 2 dingen nodig, IP forwarding op de router (deze stuurt dan verzoeken door naar het netwerk waar deze wellicht te vinden is) en firewall regels die communicatie tussen de twee netwerken toestaan.

Hierna wens je nog 1 ding, dat communicatie van br1 naar br0 niet mag voor al het verkeer dat niet naar pihole gaat.

Ik zou zeggen begin met de noodzakelijkheden. Voeg regels toe die al het verkeer tussen de twee netwerken toestaan en probeer heen/weer te pingen.

[Frogmen]

Waarom stel je niet gewoon op de DHCP server van je gastennetwerk 8.8.8.8 in als DNS server bijvoorbeeld? Scheelt een hoop configureren. Ik ken zelf de Tomato software niet, maar heb je bridges en vlans nodig, kan het niet met alleen VLAN's ?

[terror538]

Of gewoon de DNS server van je router laten forwarden naar de pi?
Dan deel je gewoon via dhcp voor ieder subnet het router ip uit voor de dns

[Toet3r]

terror538 schreef op dinsdag 24 juli 2018 @ 19:46:
Of gewoon de DNS server van je router laten forwarden naar de pi?
Dan deel je gewoon via dhcp voor ieder subnet het router ip uit voor de dns

Dat werkt wel maar dan werken de stats op de pi-hole niet. Als ik dan een domain handmatig moet whitelisten moet ik door een enorm lange lijst gaan zoeken van domains die door alle clients zijn bezocht.

Het is me ondertussen gelukt.
het werkt door onder advanced->LAN Access bij src LAN1 (br1) src adress 192.168.2.0/24 en bij DST LAN (br0) DST adress 192.168.1.254 in te vullen. Nu kunnen de clients uit br1 wel bij de pi maar niet bij de rest van br0

Had helemaal over het hoofd gezien dat dit mogelijk was

Edit: Heb het uiteindelijk toch via iptables gedaan ipv de hier boven genoemde methode omdat die alles openzet tussen br1 en de pi. met iptables heb ik nu alleen poort 53 tcp/udp opengezet.

code:

iptables -I FORWARD -s 192.168.2.0/24 -d 192.168.1.254 -i br1 -o br0 -p tcp --dport 53 -j ACCEPT
iptables -I FORWARD -s 192.168.2.0/24 -d 192.168.1.254 -i br1 -o br0 -p udp --dport 53 -j ACCEPT

[ Voor 21% gewijzigd door Toet3r op 25-07-2018 09:03 ]