UDM SE Vreemd gedrag met WhatsApp

[Sinna]

Ik draai een gastennetwerk waarop gericht toegang beperkt wordt tot een aantal standaardprotocollen (HTTP, HTTPS, QUIC, DNS - DoT, NTP, SMTP, SMTPS, Submission, POP3S, IMAP4(S)). Deze beperkingen zijn ingesteld als firewall-regels tussen Hotspot en External.

Ik kreeg vorige week de vraag om WhatsApp ook toe te laten en dacht dat het zou volstaan om WhatsApp als app toe te staan (uiteraard als regel vóór de block-all).
De resultaten hiervan waren wisselend: bepaalde mensen konden effectief bellen, bij anderen bleef het opzetten van het gesprek op connecting staan.
Ik heb het voorlopig kunnen oplossen door TCP- en UDP-poorten 3478, 3480 en 3484 open te zetten (bron), maar hierdoor staat de firewall eigenlijk ruimer open dan ik zou willen.
Mocht ik FQDN's web.whatsapp.com en/of whatsapp.net kunnen toevoegen als network object (bron), dan zou ik deze regel verder kunnen verfijnen, maar ik zie daar binnen de UDM geen mogelijkheid toe.

Wat zie ik over het hoofd, of loop ik tegen een bug aan?

 

[Hempie]

Dit is wat AI erover zegt...

---

To add a Fully Qualified Domain Name (FQDN) in UniFi, you can use the Traffic Rules feature in your UniFi Network Controller to create firewall rules that allow or block traffic to specific domains, rather than individual IP addresses. UniFi's traditional firewall rules require IP addresses, but the Traffic Rules page allows for more dynamic, FQDN-based control, which is useful for cloud-centric environments where IP addresses change frequently.

Steps to Add an FQDN to a Traffic Rule

• Access your UniFi Network Controller: and navigate to the Settings or Traffic Management section.
• Find the Traffic Rules page .
• Create a new rule: or edit an existing one.
• Select the desired action, such as "Allow" or "Block".
• In the destination or source field, enter the FQDN you want to control, such as example.com or *.example.com.
• Configure other rule settings: as needed, such as the source or destination networks.
• Save your changes: to apply the rule.

 

[Sinna]

Bedankt voor de instructies. Ik vind echter die Traffic Rules pagina niet op een UDM SE.
Het liefst zou ik zelfs die poort-gebaseerde regel terug willen schrappen en louter op die app-gebaseerde regel draaien, maar dat lukt dus (nog) niet.

 

[Sinna]

Bij deze de reactie van mijn collega (niet AI ):

Haha daarom dat die AI zegt: "Find the traffic rules page"

Volgens mij werkt een firewall altijd met IP adressen, nooit met FQDN, anders moet een firewall bij elke nieuwe verbinding van een client computer met een webservice eerst dat FQDN gaan opvragen bij een DNS server, zeker omdat tegenwoordig de TTL zo kort gehouden wordt voor DNS entries. DNS is layer 7 (in het OSI model) en een firewall werkt op layers 3 & 4.

Normaal doet de end user computer dat DNS request, en ziet de firewall enkel verkeer met in de header een IP adres voor de bestemming, en nooit het FQDN.

De firewall kan wel de pakketjes bestemd voor DNS gaan uitlezen natuurlijk, als die niet geëncrypteerd zijn, en op basis van die inhoud dan gaan filteren, maar dat is IDS/IPS en vergt veel meer cpu tijd. Dat is layer 7. (Als je kijkt bij de capaciteit van een firewall, zie je altijd dat het aanzetten van IDS/IPS altijd de throughput serieus vermindert, omdat de cpu er zo veel tijd voor nodig heeft, dit is van belang bij de aanschaf van een firewall, die moet krachtig genoeg zijn om minstens line speed te kunnen leveren met IPS aan).

Intrusion Prevention zit op de UDM SE onder Cybersecure en staat al aan.

Maar dat is allemaal niet van belang, want ons probleem is dat we zo weinig mogelijk poorten open willen laten, en dan moeten we poorten openen wanneer een app die we willen toelaten niet werkt. (Dat is layer 4 van het OSI model .) En dat is dus in de firewall, in de UDM SE de eerste tab van de Policy Engine.

Zo, nogal een uitgebreide uitleg, alleen om te zeggen dat ik denk dat we niet anders kunnen dan de gewenste poorten te openen in de firewall .