- not DNS

also checked kernel extensions and launchd services, nothing fishy

@angristan Telnet d’abord
Et vire le filtre http pour voir si le ACK/SYN passe.

@aeris effectivement, rien ne passe

@angristan Firewall faciste ?

@aeris pas le firewall macOS en tout cas

@angristan what if you completely disable IPv6 on the interface?

@angristan 3 days later. How's going ?

@benjiprod still broken

@angristan Does it work if you use a VPN? If so then it might be your ISP

@taoeffect It's not

@angristan OK, if you have Little Snitch installed, or something similar, check that. Am guessing you already tried that though.

Then another troubleshooting step is to create another user account and see if the problem occurs there too. If not, it at least narrows things down a bit.

@angristan You say you tried with curl, but didn't specify whether that was successful or not.

Also what's the error you get, a timeout? something else?

@quad not successful with curl either

I get a timeout

@angristan To all http sites? For example if you try: "curl -v http://quad.moe" that also just leads to a timeout?

@quad affirmative

@angristan Can you try the command "lsof -i" while making http requests?

It lists all current connections and I think it works on macOS. You might have to filter a bit with grep but it should show all open connections, and to where.

Verify that your http connections are going where you expect them to and are not being intercepted/redirected somewhere strange

@angristan for example quad.moe is 185.141.156.58 or 58.185-141-156.enivest.net

Leave curl in a loop and verify that it is in fact sending http requests to one of those. If not, try to figure out where it ends up, maybe it's redirected to something like 127.0.0.1 and some port, in which case "lsof -i" should also show what is listening on that ip/port

@angristan Last suggestion I can think of on the fly is running "sudo ipfw list". Which should list current firewall rules on macOS. If some application is redirecting/hijacking http requests, it's probably been done using ipfw

@angristan Actually my bad. I forgot that macOS uses pf now. If you want to check firewall rules/forwardings it's probably "pfctl -s rules "

@quad nothing of interest with this command

I also disabled the macOS firewall entirely, but no change

@angristan Did you try to use wireguard and filter by TCP and port 80?

Unfortunately if your http stuff is being redirected, it might not show up if you use ip.dst to filter. You might also have to monitor your loopback interface (or all interfaces) rather than your ethernet interface

@angristan wireshark*

@quad

curl gives timeouts,
But I assume that the issue persist on all kinds of networks and not just yours at home?

But it sounds like you have some kind of application installed that blocks it or something

@angristan

@selea @quad yes, it happens on other networks as well. It's probably something I installed, yeah...

@angristan @selea Yes, hijacking http is typical behavior for various sketchy things. Most likely something like a VPN client, an adblocker or firewall thingy

@angristan Est-ce qu'un service HTTP sur le LAN est joignable ?

@benoit oui, localhost ça marche, LAN ça marche, et même tailscale ça marche

@angristan Donc en gros c'est que quand ça traverse un routeur.

Si tu monte un serveur http sur un autre réseau genre 10.10.10.0/24, que tu ajoute le nécessaire sur ton routeur pour router 192.168.1.0/24 <--> 10.10.10.0/24, ça marche ?

@benoit pour info quand même, si je me co à un VPN genre wireguard qui donc censé rediriger tout mon traffic, le problème est là par contre

@angristan "le problème est là par contre". Le problème disparaît ?

@benoit non, il est toujours là:

@angristan Ça affecte aussi les VMs ? VirtualBox, Multipass, lima, etc?

@benoit ça semble fonctionner depuis multipass

@angristan !! Tu peux comparer les paquets qui sortent de l'interface virtuelle et de en7 ?

@benoit dans les deux cas, tu parles des paquets qui partent de la VM ?

@benoit (je demande car dans les cas où rien ne passe (ma pane de droite), je ne vois absolument aucun paquet https://mstdn.io/@angristan/107376766761258508)

@angristan Ah oui mais y'a meme pas un SYN...? Vire les filtres, ou fait des filtres inverse.
Peut être que le paquet par pas sur ip.dst Oo?

C'est pas mal chelou ton histoire, ça m'intéresse aha.

@benoit y'a rien de rien

@angristan Et si tu scanne toutes les interfaces, on sait jamais si ça passe ailleurs, très peu probable mais bon...

@benoit pareil !

@benoit autre truc étrange: si je reboot mon mac, le port 80 fonctionne. Si je met met à faire passer des choses via ce port (même plusieurs heures après le boot, alors ça va bloquer, mais seulement au bout de quelques secondes / ou au bout d'une certaine quantité de paquet, je sais pas. Et ensuite, c'est mort jusqu'au prochain reboot

@benoit avec multipass on voit bien le paquet sortir par vmenet0 puis en7

@angristan Reste à dtruss curl pour voir les appels aux librairies, mais c'est galère à faire fonctionner dtruss sous Mac.

@angristan Y'a plus qu'à tout faire router par une VM multipass 🙃

Je n'ai plus d'idées, vue que aucun paquets sort, j'ai l'impression que ça serait aux niveau des libs du Mac.

@angristan https://www.linuxjournal.com/content/more-using-bashs-built-devtcp-file-tcpip est-ce que ça marche en parlant direct à /dev/tcp ?

@benoit

@benoit ça me rend fou je vais finir par juste tout wipe lol

@angristan Hmm non.

Un curl dans la VM, follow tcp trace dans Wireshark.
Puis un curl sur le mac, follow tcp trace.

Et essaye de voir si y'a un truc différent, genre un flag TCP ou que sais-je.

@benoit oui: