Blocking quic in policies also blocks whatsapp messenger voip calls

[allebone]

While blocking quic (under the media streaming policy) does precent dns over quic from working, it also blocks whatsapp audio calls as they use udp 443 also for their calls. How can I allow whatsapp calls while still blocking quic In general? Unfortunately the current rule is too blunt and instrument so I have had to turn it off as whatsapp audio calls are used on the network. This exposes allowing all quic traffic however.

Kind regards
P

[sy]

Hi,

QUIC is used by various applications. You can exclude (whitelist) blocked IP addresses to allow WhatsApp calls while blocking QUIC. Did you try it?

[allebone]

Yes I was hoping zenarmor had a list of ips that needed whitlisting because otherwise how can I predict what they are?

[sy]

Hi @allebone,

Yes, I agree that would be the proper way. This is a bit tricky though.
The technical challenge here is that whatsapp flow carries both QUIC AND Whatsapp
voice traffic. So, if we somehow implement a way to allow Whatsapp calls, actually
we're passing a traffic which in-fact should have been blocked since it's carrying
QUIC traffic and the ruleset enforces it be blocked.

Let me communicate this with the product team and see if they can come up with a solution.

[allebone]

Yes I agree that opening up udp443 is 100% going to make you vulnerable to dns over the same UDP port if the same destination IP has both services available on that endpoint. This is always the struggle and compromise, but in some cases it is required that the functionality can take prescience over the possible risk of allowing the traffic. This is the situation I am in since whatsapp traffic must flow, even if it means allowing quic traffic (risk is accepted due to compatibility taking precedence).

As it happens I am when a user makes a whatsapp call, if it has an issue I am now checking the logs at the exact time, finding the IP's and adding then to the whitelist for zenarmor. This is similar to what you would do your side but has the disadvantage of nobody else in the world being able to benefit from my capturing of IP's and sharing that information.  So while eventually after a few months the situation will get resolved or me, nobody else is assisted by this method.

P

[allebone]

So far adding the following IP's to zenarmor whitelist/exclusions seems to have fixed whatsapp:

1    102.132.100.62       
2    102.132.99.62       
3   Invalid, something else for different purpose.
4    157.240.19.52       
5    157.240.229.62       
6    157.240.240.62       
7    157.240.249.62       
8    157.240.254.12       
9    157.240.254.35       
10    157.240.254.62       
11    157.240.254.7       
12    31.13.66.53       
13    31.13.71.48       
14    31.13.80.12       
15    31.13.80.36       
16    31.13.80.8       
17    31.13.88.62

[guernseybunker]

Let me communicate this with the product team and see if they can come up with a solution.
« Last Edit: November 28, 2022, 09:11:41 pm by sy »

Any update from the product team please Sy?

Going forward, whatever rules / techniques / capability can be wrought to selectively drop / disable QUIC connections will be vitally appreciated as firewalls worldwide continue their descent into blindness = the new dark age of TLS 1.3, ECH (ESNI), DNS over HTTPS, and DNS over TLS, QUIC, HoQ (HTTP/3), DoQ

Is there an Opnsense working document or advisory on these emerging protocols and their implications to network visibility?


Happy DEC850 user