MikroTik: guest VLAN

[Gronaldo]

Mogge allemaal,

Ben aan het stoeien met mn MikroTik RB3011 om een gast wifi netwerk op te zetten, icm een los access point. Aan de hand van deze beschrijving lijkt dit gelukt te zijn.

Echter, in Windows zie ik nog wel de devices in het hele netwerk, dus buiten de VLAN. Ook een shared folder op een pc kan worden benaderd zonder restricties. Http toegang naar devices buiten VLAN wordt wel beblokkeerd.

Het access point heeft 2 ssid’s, waarvan alleen het guest netwerk een VLAN id heeft.

Mijn kennis is nog te beperkt dit zelf op te lossen, dus alle hulp is welkom.

[lier]

Succes en tof dat je voor MikroTik gekozen hebt.

Standaard is inter VLAN verkeer mogelijk op MikroTik routers. Om dit te blokkeren heb je een forward rule in je firewall nodig die (bijvoorbeeld) alleen verkeer toelaat naar je WAN en de rest blokkeert:

code:

/ip/firewall/filter
add action=drop chain=forward in-interface=Wifi-Guest out-interface-list=!WAN

Bovenstaande ter illustratie, hopelijk geeft het de juiste richting aan. En uiteraard kan je deze ook via de GUI aanmaken. Let op dat firewall rules altijd van boven naar beneden behandeld worden.

[mathias82]

Beetje rare tutorial lijkt mij. Ik ben zelf geen ervaring met MikroTik, maar:
1. Lease time van 10 minuten in het gastennetwerk lijkt mij wel heel kort
2. Als je 10.0.0.1 blokkeert dan blokkeer je toch de default gateway voor de gasten? Dan kunnen ze geen internet gebruiken? Wat is dan het nut van het gastennetwerk?

Wat je eigenlijke probleem betreft: zit je "hoofdnetwerk" wel op 192.168.1.0/24?

[Gronaldo]

Dank voor reacties.
@lier is deze suggestie anders dan de 2 laatste (firewall) stappen in de tutorial? De 2 regels staan onderaan de overige default firewall regels. Verplaatsen naar boven had geen effect, maar zal nogmaals testen.

@mathias82 tutorial werkt in die mate als aangegeven in mijn opening. Lease tijd idd op 24u gezet. Punt 2 kijk ik ook vreemd tegenaan…maar internet werkt wel, wellicht via sluiproute?

Guest krijgt ip uit juiste pool.

[mathias82]

Gronaldo schreef op zondag 30 januari 2022 @ 11:06:
@mathias82 tutorial werkt in die mate als aangegeven in mijn opening. Lease tijd idd op 24u gezet. Punt 2 kijk ik ook vreemd tegenaan…maar internet werkt wel, wellicht via sluiproute?

Guest krijgt ip uit juiste pool.

Vreemd dat internet werkt, maar zoals gezegd ben ik niet bekend met MiktroTik, daar zal het allicht anders werken.

Guest krijgt een juist IP, maar ben je zeker dat je hoofdnetwerk op 192.168.1.0/24 zit?

[Gronaldo]

mathias82 schreef op zondag 30 januari 2022 @ 11:08:
[...]
Guest krijgt een juist IP, maar ben je zeker dat je hoofdnetwerk op 192.168.1.0/24 zit?

Ik gebruik andere range, maar volg gehanteerde principe. Dus ja.

[Thralas]

mathias82 schreef op zondag 30 januari 2022 @ 11:08:
Vreemd dat internet werkt, maar zoals gezegd ben ik niet bekend met MiktroTik, daar zal het allicht anders werken.

Zo werkt het nu eemaal onder Linux en ook bij MikroTik. INPUT omvat verkeer dat gericht is aan adressen op de router zelf, FORWARD al het verkeer dat gerouteerd wordt.

Je kunt als guest vlan client dan nog steeds het internet bereiken (gerouteerd), alleen de router zelf niet.

Dat raakt overigens wel aan één probleempunt van deze regel: standaard deelt de router ook zichzelf uit als DNS-server (met de upstream servers als secondary). Die zou ik wél toestaan in INPUT.

Gronaldo schreef op zondag 30 januari 2022 @ 11:16:
Ik gebruik andere range, maar volg gehanteerde principe. Dus ja.

Post eens een export van je configuratie, of tenminste het hele firewall blok? Er gaat duidelijk nog iets mis, en we hebben geen glazen bol..

[Gronaldo]

@Thralas Moest even zoeken hoe de firewall regels te exporteren

LAN is 192.168.88.0/24
Guest is 10.10.10.0/24

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=input dst-address=10.10.10.1 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=192.168.88.0/24 src-address=10.10.10.0/24

Laastse 2 regels zijn volgens tutorial in OP

[Gronaldo]

Wellicht handig?

[Freeaqingme]

Heb je ingress filtering op je bridge aanstaan? Kan je ook een export tonen van de vlan config van je bridge?

[jvanhambelgium]

add action=drop chain=input dst-address=10.10.10.1 src-address=10.10.10.0/24
add action=drop chain=forward dst-address=192.168.88.0/24 src-address=10.10.10.0/24


Die eerste regel is een ietwat gekke, je maakt een fout hier. Met dit soort regel ga je geen verkeer tegenhouden om je default-gateway te gebruiken hoor. (10.10.10.1 = gateway veronderstel ik)


De 2e regel ZOU inderdaad op het eerst zicht de Guest-gebruikers moeten tegenhouden om 192.168.88.x te bereiken.

Heb je eigenlijk een goede idee WAT je eigenlijk wil bereiken met dat "Guest" netwerk ? Wat mogen die eigenlijk doen ? Enkel "Internet" ? Zorg dan ook dat vb DNS-lookups allemaal werken, want in functie hoe je setup is (vb met Pi-hole) moet je nog wat aanpassingen doen.

[Voor 22% gewijzigd door jvanhambelgium op 30-01-2022 12:49]

[Gronaldo]

VLAN filtering stond UIT. Nu even aangevinkt voor screenshot, ivm zoeken naar Ingress filtering

[Voor 12% gewijzigd door Gronaldo op 30-01-2022 12:57]

[Gronaldo]

jvanhambelgium schreef op zondag 30 januari 2022 @ 12:47:
De 2e regel ZOU inderdaad op het eerst zicht de Guest-gebruikers moeten tegenhouden om 192.168.88.x te bereiken.

Heb je eigenlijk een goede idee WAT je eigenlijk wil bereiken met dat "Guest" netwerk ? Wat mogen die eigenlijk doen ? Enkel "Internet" ? Zorg dan ook dat vb DNS-lookups allemaal werken, want in functie hoe je setup is (vb met Pi-hole) moet je nog wat aanpassingen doen.

2e regel houdt blijkbaar wel http toegang tegen van gast- naar prive-netwerk (bv web portal access point of router).
Windows shares zijn echter wel zichtbaar en toegankelijk.

Gast netwerk zou alleen toegang internet moeten geven. meer niet

[jvanhambelgium]

Soms moet je ook wat extra gaan "loggen" om dingen in kaart te brengen. Zo kan je welke "rule" hit als je vb zo'n Windows share toch kan benaderen vanuit de Guest.
Je kan ook es zien om vb die forward-regel waarin je 192.168.88.x/24 blocked voor Guest helemaal naar boven schuiven in de chain en zien of dat helpt etc,etc.

[Gronaldo]

jvanhambelgium schreef op zondag 30 januari 2022 @ 13:09:
Soms moet je ook wat extra gaan "loggen" om dingen in kaart te brengen. Zo kan je welke "rule" hit als je vb zo'n Windows share toch kan benaderen vanuit de Guest.
Je kan ook es zien om vb die forward-regel waarin je 192.168.88.x/24 blocked voor Guest helemaal naar boven schuiven in de chain en zien of dat helpt etc,etc.

Firewall regel helemaal bovenin, zelfde resultaat.
Tijdens internet verkeer zie ik data op VLAN, maar een file transfer van guest naar share op prive netwerk, toont nagenoeg alleen data op de ethernet interfaces. Vandaar mijn opmerking over een sluiproute.

[Thralas]

Gronaldo schreef op zondag 30 januari 2022 @ 13:20:
Tijdens internet verkeer zie ik data op VLAN, maar een file transfer van guest naar share op prive netwerk, toont nagenoeg alleen data op de ethernet interfaces. Vandaar mijn opmerking over een sluiproute.

Dat is inderdaad een aanwijzing dat er iets niet in de haak is.

Je kunt de torch, packet sniffer (al dan niet icm. Wireshark) of Wireshark op een van de machines gebruiken om te zien hoe dat verkeer eruitziet.

Op basis van die beschrijving lijkt het erop als je AP untagged verkeer op de een-of-andere manier naar je gastennetwerk lekt (zou niet zomaar moeten gebeuren) en je vervolgens link local IPv6 gebruikt om toch je shares te bereiken.

Je kunt lukraak met vlan filters in de weer gaan, maar ik zou eigenlijk eerst uitzoeken wat voor verkeer dat nu is zodat je weet waarom dit optreedt.

[jeroen3]

Volgens mij heb je last van fastpath.

Ik heb het guest vlan op de betreffende interfaces aangemaakt en aan een tweede bridge-guest toegevoegd.

Die tweede bridge krijgt een eigen masquerade naar internet, dhcp server etc.

[Gronaldo]

jeroen3 schreef op zondag 30 januari 2022 @ 13:52:
Volgens mij heb je last van fastpath.

Ik heb het guest vlan op de betreffende interfaces aangemaakt en aan een tweede bridge-guest toegevoegd.

Die tweede bridge krijgt een eigen masquerade naar internet, dhcp server etc.

Ai, kan je niet volgen. Bedoel je wellicht Fasttrack? hHoe te checken en op te lossen?

Echter, heb nav tip @Thralas tourch gebruikt en zou bijna zeggen dat AP de fout in gaat.
Op ethernet port 3 zie ik dit:

Het lijkt alsof alleen http data wordt voorzien van VLAN tag.
Nu heb ik aan andere AP besteld, wellicht dat dat beter gaat...

[Gronaldo]

192.168.88.100 is IP van AP. lijkt alsof file transfer vanuit dat IP wordt uitgestuurd?

[jeroen3]

Je hebt in je torch daar gewoon wat broadcast verkeer. Dat is toch niet zo gek?
Je hebt vast wat smart home spullen op wifi.

Ja, fasttrack verhindert sommige configuraties met speciale regels t.b.v. performance.
Je kunt even kijken naar het block diagram van de rb3011 of je wellicht nog iets moet aanpassen in de switch chip zelf o.i.d.

[Voor 46% gewijzigd door jeroen3 op 30-01-2022 14:41]

[Thralas]

Inderdaad, ik zie daar geen file transfers op. Probeer het nog eens terwijl je een grote file transfert.

Vink meteen ook Protocol en Port aan.

[Gronaldo]

Download vanaf internet


Onderstaand van file transfer gast naar prive share

[Gronaldo]

Snap niet waar die 60Mb blijft in de tourch data.

[jeroen3]

Je kunt dat verkeer waarschijnlijk niet zien in torch want het blijft in de switches.

[Thralas]

eth3 en eth9 zitten alleen juist niet op dezelfde switch - en dan nog, het verkeer zou je eigenlijk alsnog moeten kunnen zien met Torch.

Kan me voorstellen dat het helpt om op de bridge te capturen omdat eth3 een slave port is. Probeer dat eens @Gronaldo? En je moet na het aanvinken van Port/Protocol wel opnieuw op Start drukken

Als dat nog niet werkt, is het een gevolg van bridge fast path en kun je beter Wireshark gebruiken op één van de PCs...

[Gronaldo]

jeroen3 schreef op zondag 30 januari 2022 @ 15:52:
Je kunt dat verkeer waarschijnlijk niet zien in torch want het blijft in de switches.

Poort 3 (AP) en 9 (PC met shared folder) worden gebruikt

[Gronaldo]

@Thralas Sorry (noob op dit gebied )

[jeroen3]

Volgens mij raakt je verkeer de cpu nauwelijks en gaat het niet door de firewall heen.
Als je nog zin hebt kun je dit bestuderen.
https://help.mikrotik.com...S/Packet+Flow+in+RouterOS

Er is ook nog een /interface bridge filter firewall, wellicht moeten je rules dan daarin?
Ik heb alleen single-switch RB's dus ik heb dit nog nooit geprobeerd.

Ik kijk zo even in de packet flow, en kennelijk is er ook dit vinkje in de bridge settings. Helpt dat? (safe-mode!)


Anders:
Maak eens een nieuwe bridge-guest aan, en je vlan onder eth3, voeg die toe aan de bridge-guest.
De cpu moet dan routeren tussen bridge-local en bridge-guest of WAN, en zo forceer je het gebruik van de firewall.

Dit bottlenecked verkeer tussen normaal en gasten via de cpu, maar dat blokkeren is precies je doel toch?

[Voor 23% gewijzigd door jeroen3 op 30-01-2022 16:44. Reden: use-ip-firewal]

[Gronaldo]

jeroen3 schreef op zondag 30 januari 2022 @ 16:41:
Er is ook nog een /interface bridge filter firewall, wellicht moeten je rules dan daarin?

Die kan ik niet vinden ergens?

jeroen3 schreef op zondag 30 januari 2022 @ 16:41:
Maak eens een nieuwe bridge-guest aan, en je vlan onder eth3, voeg die toe aan de bridge-guest.

Extra bridge kan, maar VLAN kan of aan die Bridge, of aan eth3, niet beide toch?

[Gronaldo]

jeroen3 schreef op zondag 30 januari 2022 @ 16:41:
Ik kijk zo even in de packet flow, en kennelijk is er ook dit vinkje in de bridge settings. Helpt dat? (safe-mode!)
[Afbeelding]

Had ik ook al gevonden.....helaas, geen oplossing.

[Gronaldo]

@jeroen3 @Thralas @jvanhambelgium @mathias82 @Freeaqingme
Allen dank voor jullie inspanningen, maar deze 'simpele' vraag blijkt toch lastiger dan gedacht.
Zoals aangegeven, ontvang ik snel een ander AP, ga hiermee eens kijken of dit wellicht een oplossing biedt. Kan natuurlijk ook bug in firmware huidige AP zitten. Uitkomst laat ik dit weten.

Suggesties tussentijds zijn meer dan welkom, natuurlijk.

Fijne dag verder!

[ndonkersloot]

@Gronaldo
Ik gebruik zelf ook Mikrotik (CCR1009 + 3 cAP AC's) en heb ook een gasten netwerk ingericht. Zit nu op mijn telefoon, en kan later nog eens kijken en indien gewenst mijn config delen maar mijn gevoel zegt dat het bij jou mis gaat door fasttrack.

Fasttrack is een firewall rule die standaard aanwezig is en er voor zorgt dat related en established verkeer rechtstreeks doorzet zonder verdere firewall rules, queues of iets anders langs te gaan. Dit verminderd CPU belasting en kan daardoor de performance ten goede komen maar is in sommige gevallen, zoals een VLAN ongewenst zijn (afhankelijk van de inrichting).

Wil je is testen met die rule uit? Als dat niet werkt zal ik is in beknopte stappen posten hoe ik dit geconfigureerd heb.

Even een andere vraag, gebruik je CAPsMAN voor de inrichting van de AP of gewoon los op de AP zelf.

De andere AP die je ontvangt, is dat nog MikroTik of een ander merk?

[Gronaldo]

@ndonkersloot dank voor reactie. In de firewall settings heb ik getest met fasttrack disabled. Geen succes.
In de bridge instellingen (dacht ik) kan je ook fasttrack uitvinken. Weet niet meer of ik dat gedaan heb.

Maar het is dus niet zo dat de firewall regels niets doen. Alleen niet afdoende.

Nieuw AP is Netgear, WAX214, geen MT dus. Huidige is TP-LINK EAP245

[mathias82]

Gronaldo schreef op zondag 30 januari 2022 @ 17:15:
@jeroen3 @Thralas @jvanhambelgium @mathias82 @Freeaqingme
Allen dank voor jullie inspanningen, maar deze 'simpele' vraag blijkt toch lastiger dan gedacht.
Zoals aangegeven, ontvang ik snel een ander AP, ga hiermee eens kijken of dit wellicht een oplossing biedt. Kan natuurlijk ook bug in firmware huidige AP zitten. Uitkomst laat ik dit weten.

Suggesties tussentijds zijn meer dan welkom, natuurlijk.

Fijne dag verder!

Aan het AP zal het niet liggen. Pakketjes voor een ander (V)LAN moeten altijd gerouteerd worden. Het AP kan ze net zomaar van het ene (V)LAN naar het andere sturen. Het verkeer moet door de router en deze laat het dus om een of andere reden gewoon door.

Toevallig geen IPv6 in gebruik? Misschien vindt het verkeer lang daar zijn weg.

Ik weet niet of je in MikroTik de firewall rules makkelijk kan laten loggen / debuggen? Dan kan je zien wat er juist gebeurt.

[jeroen3]

Gronaldo schreef op zondag 30 januari 2022 @ 17:09:
[...]

Die kan ik niet vinden ergens?


[...]

Extra bridge kan, maar VLAN kan of aan die Bridge, of aan eth3, niet beide toch?

Dat vinkje zit achter de knop settings in het menu bridge in winbox.

Vlan alleen onder eth3, en je vlan virtuele interface toevoegen aan bridge-guest.
Je moet dan ook zorgen dat bridge-guest kan routeren.

Ik heb daarvoor de volgende rules:
Een forward rule die routes tussen guest/24 en main/24 dropt.
En een input rule die guest/24 naar de router zelf dropt, behalve icmp.
En een masquerade met guest/24.

[Thralas]

jeroen3 schreef op zondag 30 januari 2022 @ 16:41:
Er is ook nog een /interface bridge filter firewall, wellicht moeten je rules dan daarin?

Nee..

Het verkeer zou per definitie gerouteerd moeten worden (via 10.10.10.1). Als er een andere route is (bv. switched) dan moet je dat geheel weghalen. Bridge filtering op IP heb je niet nodig.

Anders:
Maak eens een nieuwe bridge-guest aan, en je vlan onder eth3, voeg die toe aan de bridge-guest.
De cpu moet dan routeren tussen bridge-local en bridge-guest of WAN, en zo forceer je het gebruik van de firewall.

Zou niets uit moeten maken. De enige ingress die er zou moeten zijn is 10.10.10.1 op vlan 10. Het andere vlan kan alleen maar bereikt worden door te routeren en dat zou de firewall tegen moeten houden.

Het screenshot dat TS eerder postte wijst sterk op onbedoeld geswitcht verkeer, heeft alle schijn van een vlan screwup ergens.

mathias82 schreef op zondag 30 januari 2022 @ 18:37:
Toevallig geen IPv6 in gebruik? Misschien vindt het verkeer lang daar zijn weg.

Yes, dat zou een mogelijke bypass op kunnen leveren als er (onbedoelde) link local-connectiviteit is.

Ik weet niet of je in MikroTik de firewall rules makkelijk kan laten loggen / debuggen? Dan kan je zien wat er juist gebeurt.

Je kunt een log-action toevoegen (of een aparte log rule), maar ik vrees dat je er hier niet zoveel mee opschiet omdat het er alle schijn van heeft dat het een L2 issue is.

Gronaldo schreef op zondag 30 januari 2022 @ 17:15:
Suggesties tussentijds zijn meer dan welkom, natuurlijk.

Ik raad aan om toch eerst duidelijk te krijgen wat er nu precies misgaat. Drie suggesties/opmerkingen:

• Torch helpt blijkbaar niet - L2 issue?
• Probeer eens te achterhalen hoe je de share kunt benaderen vanaf het gastennetwerk. Gaat dat op NetBIOS name? Zoja: wat laat nbtstat /c zien (wel eerst de share benaderen)?
• Alternatief voor bovenstaande: Wireshark. Ik blijf het gewoon herhalen

[ndonkersloot]

Ik heb nu op m'n notebook nog eens gekeken naar de config die je gepost hebt en de tutorial.
Kan eigenlijk enkel bedenken wat Lier al als eerste gepost heeft, een firewall rule die forward verkeer dropt.

Heb zelf zoiets staan:

code:

add action=drop chain=forward comment="Drop ALL from internal > guest" connection-state=invalid,established,related,new,untracked dst-address-list="Guest subnet" log=yes log-prefix=_drop-internal src-address-list="Internal subnet"
add action=drop chain=forward comment="Drop ALL from guest > internal" connection-state=invalid,established,related,new,untracked dst-address-list="Internal subnet" log=yes log-prefix=_drop-guest src-address-list="Guest subnet"

Waar bij de address-list objecten het subnet van het betreffende netwerk is.
Altijd lastig troubleshooten, netwerk issues zonder dat het je eigen netwerk is . De suggesties van Thralas lijken me het beste om op te volgen.

[Gronaldo]

@Thralas
C:\Users\R>nbtstat /c

Ethernet:
Node IpAddress: [0.0.0.0] Scope Id: []

No names in cache

Bluetooth-netwerkverbinding:
Node IpAddress: [0.0.0.0] Scope Id: []

No names in cache

Wi-Fi 2:
Node IpAddress: [10.10.10.254] Scope Id: []

No names in cache

LAN-verbinding* 12:
Node IpAddress: [0.0.0.0] Scope Id: []

No names in cache

LAN-verbinding* 13:
Node IpAddress: [0.0.0.0] Scope Id: []

No names in cache

Benaderen shares, via Windows verkenner, PC zichtbaar in netwerkomgeving en dubbelklikken toont share.

[Gronaldo]

@ndonkersloot regels zoals getoond aangepast en toegevoegd. bovenaan in lijst gezet....geen resultaat

code:

/ip firewall filter
add action=drop chain=forward comment="Drop ALL from guest > internal" connection-state=invalid,established,related,new,untracked dst-address-list=192.168.88.1/24 log=yes log-prefix=\
    _drop-guest src-address-list=10.10.10.0/24
add action=drop chain=forward comment="Drop ALL from internal > guest" connection-state=invalid,established,related,new,untracked dst-address-list=10.10.10.0/24 log=yes log-prefix=\
    _drop-internal src-address-list=192.168.88.0/24
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward dst-address=192.168.88.0/24 log=yes log-prefix=blok-g2p protocol=tcp src-address=10.10.10.0/24
add action=drop chain=input dst-address=10.10.10.1 log=yes log-prefix=blok-g210.1 src-address=10.10.10.0/24

@Thralas IPv^6 volledig gedisabled (stond op default settings)....geen resultaat

Wireshark heb ik totaal geen ervaring mee, zou heel nieuw traject worden. Bovendien zou ik niet weten wat ik zoek, vrees ik.

Nogmaals, configuratie is nagenoeg default, op wijziging hier besproken na, de punten uit de tutorial en een enkele testinstelling qua port-forwarding/NMT/email script voor logs, omdat de router helemaal nieuw is voor me.

Router nog gereboot...geen resultaat

[Voor 60% gewijzigd door Gronaldo op 30-01-2022 20:30]

[Gronaldo]

Overigens nieuwe firewall regels laten loggen, onderstaand resultaat van gast naar prive regel;

code:

 20:34:53 firewall,info blok-g2p forward: in:VLAN-guests out:bridge, src-mac xxxxxxx, proto TCP (SYN), 10.10.10.254:64161->192.168.88.100:80, len 52
 20:34:53 firewall,info blok-g2p forward: in:VLAN-guests out:bridge, src-mac xxxxxxx, proto TCP (SYN), 10.10.10.254:64162->192.168.88.100:80, len 52
 20:34:54 firewall,info blok-g2p forward: in:VLAN-guests out:bridge, src-mac xxxxxxx, proto TCP (SYN), 10.10.10.254:64163->192.168.88.100:80, len 52
 20:35:01 firewall,info blok-g2p forward: in:VLAN-guests out:bridge, src-mac xxxxxxx, proto TCP (SYN), 10.10.10.254:64161->192.168.88.100:80, len 52
 20:35:01 firewall,info blok-g2p forward: in:VLAN-guests out:bridge, src-mac xxxxxxx, proto TCP (SYN), 10.10.10.254:64162->192.168.88.100:80, len 52
 20:35:02 firewall,info blok-g2p forward: in:VLAN-guests out:bridge, src-mac xxxxxxx, proto TCP (SYN), 10.10.10.254:64163->192.168.88.100:80, len 52

[Thralas]

Gronaldo schreef op zondag 30 januari 2022 @ 20:15:
@ndonkersloot regels zoals getoond aangepast en toegevoegd. bovenaan in lijst gezet....geen resultaat

code:

/ip firewall filter
add action=drop chain=forward comment="Drop ALL from guest > internal" connection-state=invalid,established,related,new,untracked dst-address-list=192.168.88.1/24 log=yes log-prefix=\
    _drop-guest src-address-list=10.10.10.0/24
add action=drop chain=forward comment="Drop ALL from internal > guest" connection-state=invalid,established,related,new,untracked dst-address-list=10.10.10.0/24 log=yes log-prefix=\
    _drop-internal src-address-list=192.168.88.0/24

Die address list is bogus, dat is de naam van een lijst als het goed is, de ranges zijn vervolgens onderdeel van de lijst.

@Thralas IPv^6 volledig gedisabled (stond op default settings)....geen resultaat

Het wordt steeds vreemder..

Wireshark heb ik totaal geen ervaring mee, zou heel nieuw traject worden. Bovendien zou ik niet weten wat ik zoek, vrees ik.

Niet zo moeilijk: het source en destination IP van het CIFS-verkeer. Als je daar een werkende sessie naar 192.168.88.0/24 ziet is er iets heel raars aan de hand.

Misschien volstaat onderstaande ook wel, maar het blijft een beetje gissen en hopen dat het de gewenste output geeft, terwijl Wireshark het gegarandeerd laat zien.

ipconfig /a
arp /a
ping LAPBOX

Welke versie van RouterOS draai je trouwens?

[Gronaldo]

@Thralas in mijn onkunde heb ik suggestie van @ndonkersloot aangepast naar wat ik dacht mijn ip-ranges. Fout dus, begrijp ik. Dit corrigeren en zo ja hoe/waar?

Wireshark zal ik zeker proberen, want dit kan toch niet onopgelost blijven.
Wordt morgen, nu even iets anders doen, anders droom ik van firewalls, ip-demonen etc!

Router draat op 7.1.1 uit mn hoofd, de laatste in ieder geval.

[Gronaldo]

@Thralas
Pingen naar prive netwerk lukt prima (maar IPv6?!)
C:\Users\R>arp /a

Interface: 10.10.10.254 --- 0x8
Internet Address Physical Address Type
10.10.10.1 64-d1-54-xxxx dynamic
10.10.10.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

C:\Users\R>ping lapbox

Pinging Lapbox [fe80::f8f7:384a:xxxx] with 32 bytes of data:
Reply from fe80::f8f7:384a:xxxx: time=1ms
Reply from fe80::f8f7:384a:xxxx: time=2ms
Reply from fe80::f8f7:384a:xxxx: time=2ms
Reply from fe80::f8f7:384a:xxxx: time=2ms

Ping statistics for fe80::f8f7:384a:xxxx:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms

[Gronaldo]

Her en der enige privicy getracht door te voeren

[Voor 20% gewijzigd door Gronaldo op 01-02-2022 07:35]

[Gronaldo]

File transfer


Zie geen directe toegang op IPv4 naar 192.168.88.x

[jeroen3]

Gronaldo schreef op zondag 30 januari 2022 @ 21:12:
Router draat op 7.1.1 uit mn hoofd, de laatste in ieder geval.

Oei, wellicht voor beginners makkelijker om stabiele ros 6 long-term te gebruiken.
Maar dat is mijn mening.
https://forum.mikrotik.com/viewtopic.php?t=182699

[Voor 8% gewijzigd door jeroen3 op 31-01-2022 12:54]

[Thralas]

Gronaldo schreef op maandag 31 januari 2022 @ 11:56:
@Thralas
C:\Users\R>ping lapbox

Pinging Lapbox [fe80::f8f7:384a:xxxx] with 32 bytes of data:
Reply from fe80::f8f7:384a:xxxx: time=1ms

Dus toch IPv6.

Zie geen directe toegang op IPv4 naar 192.168.88.x

Maar wel precies wat ik en @mathias82 eerder opperden: je kunt de machine blijkbaar via (link local) IPv6 bereiken (te zien aan port 445 is dit je filetransfer over CIFS). Dat betekent dat je vlan-scheiding inderdaad niet goed werkt en je dus vanaf het gastennetwerk bij je reguliere (untagged?) vlan kunt.

Een Google query op goed geluk bevestigt wat we hier zien:

quote: https://www.reddit.com/r/...245_ipv6_support/fmitaf8/

If you set up a second VLAN to broadcast a guest network, IPv6 broadcast traffic from your untagged VLAN will leak onto ALL tagged VLANs that this AP has access to (this includes DHCP6 packets). You'll see devices on your guest network pick up IPv6 addresses from both your tagged and untagged VLAN simultaneously,

Je access point is brak en implementeert het guest 'vlan' op een hele dubieuze manier (dit zou echt niet zomaar moeten kunnen).

Gezien je al een nieuwe hebt besteld: probleem opgelost. Mocht je dit access point toch nog willen gebruiken, dan kun je een bridge filter rule gebruiken om IPv6 frames op de poort van het AP te filteren. Niet heel mooi, maar zou praktisch gezien moeten werken.

[Gronaldo]

Thralas schreef op maandag 31 januari 2022 @ 19:14:
[...]
Je access point is brak en implementeert het guest 'vlan' op een hele dubieuze manier (dit zou echt niet zomaar moeten kunnen).

Dat gevoel had ik ook al, zoals ik eerder aangaf. Maar dat het IPv6 was, had ik niet verwacht. Dacht meer een basic fout in uitsturen data zonder juiste tagging.
Maar toch, IPv6 in de router staat nu geheel disabled, maar toch vindt het zijn weg…

Is het daarnaast nog wel raadzaam om naar versie 6 ROS terug te stappen, zoals door @jeroen3 voorgesteld?
Qua features heb ik v7 niet nodig, maar ga er vanuit dat security-technisch de recentere versies beter zijn.

[Thralas]

Gronaldo schreef op maandag 31 januari 2022 @ 19:34:
Maar toch, IPv6 in de router staat nu geheel disabled, maar toch vindt het zijn weg…

Als je het op je router uitzet dan deelt deze geen globale adressen uit (als je ISP die heeft). IPv6 heeft daarnaast altijd ook een link local adres (fe80::...), dat werkt altijd tenzij je de hele IPv6 stack uitzet.

Is het daarnaast nog wel raadzaam om naar versie 6 ROS terug te stappen, zoals door @jeroen3 voorgesteld?
Qua features heb ik v7 niet nodig, maar ga er vanuit dat security-technisch de recentere versies beter zijn.

Als je geen problemen ondervindt dan zou ik op v7 blijven. Niet persé securitytechnisch beter, wel toekomstvaster en in bepaalde gevallen sneller (zie bv. bridge filtering in fast path in v7.2).

[Gronaldo]

@Thralas @jeroen3 @mathias82 @jvanhambelgium @ndonkersloot @lier Allen heel erg bedankt voor jullie hulp!

[Voor 3% gewijzigd door Gronaldo op 31-01-2022 21:13]

[Gronaldo]

Nabrander:
AP vervangen door Netgear WAX214 en.......direct werkend zoals verwacht.
Bewijs geleverd

[Gronaldo]

Nabrander 2
Na voorgaande mijn proefopstelling definitief geïnstalleerd te hebben, blijkt de oplossing toch niet gevonden te zijn. Ook met het nieuwe AP blijft het privé netwerk te pingen en shares te benaderen via IPv6. Waarom dit eerst wel goed leek te gaan is me niet duidelijk.

Ondertussen gevonden dat het AP ook zelf een gast-netwerk optie biedt en deze nu in gebruik genomen. Dit werkt wel zoals gewenst en verwacht. Jammer, ik had het liever via de MT router en VPN geregeld...

[Thralas]

Tja, de kans dat je twee keer een brak AP koopt is niet zo groot, waarschijnlijk is het toch echt een misconfiguratie dit keer.

Hoe heb je het AP geconfigureerd?

quote: https://www.downloads.net...4/WAX214_WAX218_UM_EN.pdf

VLAN isolation

To prevent clients on different VLANs from communicating with each other, select
the Enable radio button, and enter the VLAN ID in the ID field. By default, this option
is disabled.

L2 isolation
To prevent WiFi and LAN clients on the same access point from communicating with
each other, select the Enable radio button.

.. om maar wat te noemen.

Ik begrijp die optie overigens niet, want ik neem aan dat het AP geen router is, dus hoezo vindt er dan uberhaupt communicatie tussen vlans plaats.

De eerdere opmerking over een port mirror geldt ook nog steeds: daarmee kun je direct bepalen of het aan de router of AP ligt.

[Voor 18% gewijzigd door Thralas op 06-02-2022 15:54]

[Gronaldo]

Instellingen in AP en MT zoals eerder aangehaald. Dus VLAN in AP voor gast netwerk ingesteld en ook L2 isolation aangezet. Deze opties zouden alle communicatie tussen VLANs moeten blokkeren.

Windows share staat op Windows 11 pc, maar of dat nog iets kan/mag uitmaken lijkt me onlogisch.

Nu dus gast wifi gebruikt binnen AP, met eigen DHCP range.

[CeesBak]

Een paar weken aan het stoeien met MikroTik routers. Oef, dat is wel bijzonder wennen en leren! Ik heb een RB750GR3 in de meterkast en twee andere via CAPsMAN verbonden. Apart gastnetwerk waar ik voor de gasten "Local Forwarding"en "Client to Client Forwarding" uit heb staan. Verder heb ik in de firewall van IPv4 de volgende regel opgenomen:

code:

/ip firewall filter
add action=accept chain=forward\
    comment="Alles van Gast Netwerk direct naar buiten"\
    out-interface=ether1 src-address=192.168.10.0/24

Hierbij heeft een apparaat op het gatsnetwerk geen enkele kans bij mijn prive netwerk te komen. Als ik een scan doe op een aangesloten apparaat op het gastnetwerk zie ik inderdaad alleen het apparaat zelf en het adres van de gateway. Nu heb ik de volgende vragen:

1) Is hier iets mis mee?
2) Ik merk dat ik mijn privé netwerk IPv6 volledig aan de praat heb. Echter als ik aangesloten ben op mijn gastnetwerk dan werkt IPv6 in het geheel niet???