Gestisco una VPN WireGuard ospitata su Vultr su OpenBSD. L’ho configurata per ascoltare sulla porta 53 dato che il traffico WG è UDP, e dubitavo che la maggior parte dei firewall bloccasse il traffico UDP inviato lì. Bene, si scopre che T-Mobile fa qualcosa con il traffico WireGuard inviato sulla porta 53. Farla funzionare sul mio telefono funzionava sulla mia rete Wi-Fi domestica (Verizon FiOS, di cui parlerò sotto), ma non funzionava affatto sotto la connessione LTE di T-Mobile. Esaminando il traffico sul server con tcpdump ho rilevato che sulla rete T-Mobile, veniva inviato una quantità molto piccola di traffico iniziale e poi niente più. Passando il server alla porta 443 ha funzionato bene.
Per quanto riguarda Verizon, invece, era estremamente lento (sebbene funzionante) usando la porta 53, ma molto veloce con la porta 443. Suppongo che limitino il traffico DNS perché di solito è una quantità piccola di dati e non viene inviata molto spesso rispetto a HTTPS, che ha una priorità alta. Suscettibile che anche T-Mobile faccia qualcosa di simile, ma potrebbe anche essere che facciano DPI e abbattano i pacchetti.
Solo per info nel caso abbiate problemi di connessione strani. Qualcun altro con esperienze simili?
Non sorprende.
Gli attacchi di amplificazione DNS e una tecnica di DoS comune e devastante quindi dovresti praticamente sempre bloccare la porta 53 in ingresso, motivo per cui probabilmente T-Mobile blocca il traffico sulla porta 53 che non è DNS.
Non ho avuto problemi con T-Mobile, Verizon né AT&T sulla porta predefinita di WireGuard. Non c’è motivo di fare giochi. Funziona e funziona bene con velocità molto buone.
T-Mobile potrebbe bloccare il traffico non DNS sulla porta 53. Per quanto riguarda le velocità lente su altre reti, potrebbe essere a causa della gestione della rete di Vultr. Anche OVH fa lo stesso.
Quindi ho trovato questo post mentre indagavo alcuni problemi con il mio tunnel VPN su T-Mobile.
Usavo VPN client Pro e di solito era configurato con tre peer verso casa, uno su una porta a caso alta, uno su UDP 443, e uno su UDP 53.
A causa dei miei problemi, la porta UDP alta non funzionava, e anche avevo problemi con UDP 53.
Dopo aver catturato alcuni pacchetti, vedevo sul UDP 53 l’inizio del handshake e la risposta, ma poi i dati di trasporto non seguitavano mai, inoltre non sono sicuro che la risposta dell’handshake sia mai arrivata al “client”.
Quindi due possibilità, T-Mobile sta bloccando la risposta dell’handshake verso il “client”/peer sulla rete T-Mobile, o sta bloccando i dati di trasporto, cosa meno probabile.
Mi sembra interessante che permettano il traffico in uscita che NON è DNS su UDP 53, ma probabilmente bloccano il traffico in ingresso di ritorno che non sembra una risposta DNS.
Devo chiedere, perché usare la porta DNS riservata per qualcos’altro che DNS? WG funziona bene sulle porte di default con AT&T, Sprint, Verizon e T-Mobile. Non vedo motivo di non usare le impostazioni di default, ma se vuoi cambiare, ti sconsiglio di usare una porta ben nota e riservata.
Giusto! La nostra scuola è per difendersi dagli attacchi DoS, possiamo usare solo il DNS della scuola (non possiamo usare Google, Cloudflare… DNS pubblici)
Anche T-Mobile credo.
Usi la porta DNS per sfuggire ai firewall su reti condivise che cercano di bloccare gli utenti che usano porte in uscita diverse da 80, 443/tcp e 53/udp.
In questo caso, il traffico WireGuard in uscita sulla porta standard sarebbe bloccato, ma OP può passare.
possiamo usare solo il DNS della scuola (Non possiamo usare Google, Cloudflare… DNS pubblici)
Ci sono buone ragioni per questo, ma la difesa contro DoS non è di solito tra queste. Un attacco di Amplificazione DNS avviene quando un risolutore DNS ricorsivo è aperto su internet senza protezioni adeguate.
Se non puoi usare Google o Cloudflare, è più probabile che sia una misura di filtro. La scuola può inserire “entry” false nel risolutore DNS per impedirti di raggiungere certi siti. Quindi, invece che pornhub risolva l’IP reale, risolve a un IP nullo come 0.0.0.0 o 127./8. Quando cerchi di aprire la pagina web, ottieni un errore, mentre usando Google o Cloudflare otterresti l’IP reale.
Il modo migliore ed più semplice per evitare di essere usato in un attacco di Amplificazione DNS è mantenere la porta 53 in ingresso chiusa sul firewall.
Sì, questo è il mio problema. Voglio usare questa rete con un firewall abbastanza aggressivo che blocca praticamente tutto tranne che 80, 443, o 53. So che la porta di default non funzionerà perché l’ho già provato.
Vedremo se permette traffico UDP non TLS in uscita sulla porta 443.
Gestisco le interfacce wg sulla porta 443/udp e non sembra essere bloccato, YMMV.
Intendo dire che bloccare tutte le connessioni UDP in uscita non è la soluzione migliore ovunque.
E anche se tengo aperti sia TCP che UDP, non ho mai avuto problemi usando solo UDP.
Sì. Oppure il DNS sinkholing è un altro termine che ho sentito funzionare nei SOC.