Raw UDP socket support in macos/ios #79
Comments
Mrc527
changed the title
|
What version are you using? Can you post the part of the client log when it fails? |
|
Hi @yarrick, I'm currently building my executables against the latest "master" branch commit here. I do not get any error message. I simply always get "....failed". Even when trying from a working internet connection, and also from the same LAN as the server. I'm pretty sure it's about macOS/iOS, somehow. `bin % sudo ./iodine -4 -f -P pass dns_ip domain No tun devices found, trying utun |
|
I don't see any reason why this would be platform dependent. Was the shown server address the expected one? Can you capture the traffic the server receives and see if it gets anything? If it doesn't, log the traffic from the client instead. |
|
@yarrick I believe the server is not getting much Here is a tcpdump from the server Here is attempting a raw login. But no packets are received. 20:50:52.673019 IP CLIENT_HOST.16436 > SERVER_HOST: 3248 [1au] NULL? yrb2hb.i.xxx.ch. (46) |
|
And here is the client side: `20:56:52.712790 IP CLIENT_HOST.61189 > SERVER_HOST: 22800+ NULL? yrbhd4.i.xxx.ch. (35) Here the client tries to do raw login. Again, nothing is recorded. 20:57:02.873050 IP CLIENT_HOST.61189 > SERVER_HOST: 53708+ [1au] NULL? yrbhec.i.xxx.ch. (46) |
Oh sorry I forgot to answer this. --> Yes, the server address is the correct one. |
|
Is the |
Yes |
|
The raw login is not a packet following the DNS format, but still using port 53. Could tcpdump possibly filter them out? Can you post your current tcpdump command? Can you run it with |
|
This is the tcpdump command I executed, I think it should be correct. Do you want me to run it differently? |
|
That should be fine. This is how it looks for me: Is there any firewall thing that could block it? |
|
Nope, same network as the windows device, which works perfectly. iOS (both iPad and iPhone) and macOS are not 😞 |
|
I also tried with an older Mac, just to rule out the possibility it's a newer macOS security policy. If that's the problem, it's there since Big Sur (11.6.2) |
|
I was just about to ask if this was iOS only. By firewall I meant some software running on the client device that could filter this traffic out |
|
There is just the standard macOS firewall active but that's only filtering incoming connection (and I allowed iodine). |
|
Anything else we could try? |
|
I don't have any ideas. It would be interesting to know if other users are seeing this as well - the feature has existed a few years without earlier mentions of this. |
|
Can it be a server issue? I mean, I tried with multiple clients and all of the macOs-like behave the same. The only thing I did not change is the server, maybe you could setup a server and share the link with me to see if we can understand what happens. 🤷♂️ |
|
FYI I tried on newest MacOS / iOS releases (Ventura and iOS/iPadOS 16.1) and the issue is still there 😞 |
|
Since we didnt see the login packet leave the client I find it hard to blame the server. |
|
I experience the same problem with a client on MacOS Mojave (10.14). The login packet(s) apparently is never sent, only standard dns is captured on tcpdump (on client), no "malformed" packets leave the interface. Built from tag v0.8.0. |
|
How are you running it on iOS btw? Did you jailbreak your device? |
|
I'm using it via Purple Haze, no jeailbreak. But it's affected by this issue, quite annoying as it limits the bandwidth on many networks |
|
Can someone record a log what strace says while the raw login is attempted? Would be interesting to know the sendto() return value |
|
sendto(0x4, 0x7FFEEDB45660, 0x24) = 36 0 Does this help? I'm clueless of coding, let alone debugging, at this level. full dtrace of "trying raw login"dtrace: system integrity protection is on, some features will not be available... |
|
Thanks, it looks like the sendto() call doesn't immediately fail at least. I guess something else is filtering it out edit: Unless the dtrace errors actually mean that something failed |
The log is full of this specific error, that is apparently caused by System Integrity Protection. |
This makes a lot of sense, to me it's evident this is a (security) limitation imposed by Apple somehow. |
|
It would be interesting to see if this still happens with SIP off |
|
Did |
|
Any progress? I am having this issue as well. |
|
I don't have an apple machine so it is not easy for me to debug. Can someone test with the mac running iodined and see if it can accept incoming raw login packets (with pcap)? Can be done inside a lan with a fake domain |
|
@yarrick From looking in wireshark, it seems to not be sending the raw login packet at all.
So there seems to be some inconsistency with the packets as well. Also, I was using Google's dns server (8.8.8.8) as the upstream. |
|
macOS ventura 13.5 (22G74) here, I'm not seeing this problem, and my csr status seems to be intact: I'm starting it as root, as I assume this is needed for creation of the utun device. |
|
@m0yellow Are you specifying the tunneling device? On 0.7.0, I get the error: On 0.8.0, I get this output: If I specify the tunnel I am on macOS Ventura 13.5.1. SIP is enabled. One thing I did different is I built 0.7.0 from source by checking out the 0.7.0 branch instead of installing it via macports. |
|
Something else I noticed was that when I leave the ping command running, there are a few times where it gets a response. The rest say |
I installed iodine (0.8) with brew. I get the following, in the beginning: I think it is cycling through all the tun devices until one free is found. In fact, after this message, it works normally (except for the raw tunnel of course). @m0yellow if you have brew, can you try installing it via brew and test if that version works for you with the raw tunnel? |
reads like a query limit on the DNS Server relaying the tunnel packets to me. Are you able to try raw mode? |
As I don't use brew, I reproduced the brew build by looking it up manually: Does it help to produce a pcap of the raw exchange? I'll try now for curiosity, and upload if anybody is willing to look at it. |
Yeah, I also get some bad encoding but that's not a big deal. And given I also get the same on iPad and iPhone, I guess it's somehow related to a security measure by Apple. But I cannot explain why it works for you. Maybe it's because your server is on the same LAN as your machine? Maybe connecting to a local host is not triggering the Apple security. Can you try setting up the server on a public IP and connecting to that via internet (like tethering from your mobile) please? |
|
MacOS and iOS Darwin are FreeBSD based. And there are stackoverflow questions that mention error22 EINVAL on BSD/Mac in context of raw UDP, when the same code works on Linux. The details are way beyond me, but maybe you can use FreeBSD to debug that Mac stuff? :) |
@m0yellow This output was with raw mode failing from the client when I ran this |
I missed that detail. Thanks for pointing it out. To write things clear: I had 0.7.0 running fine, now I have 0.8.0 running fine on macOS, connecting to a linux VM remotely. Pinging in the tunnel works. As the VM is far away, I can't tell if Jitter is network jitter, or implementation wise. Any ideas how I can reproduce the problems? |
|
@m0yellow So even connecting to a public IP (not in the reserved/private space) works for you? This is really mysterious then, as I still have the same issues as always. I’m currently updating to 13.5.1 but I do not think this will make any difference, unfortunately. UPDATE: it does not work even with 13.5.1 😞 I repeated the test and I could not see any outgoing RAW UDP packet going out of my machine, tested with WireShark. Would be nice if we could analyse the macOS logs to see what/why is blocking those packages…any clue? P.S. @m0yellow I’m trying with both firewall on and off. I also manually disabled the Packet Filter with |
|
to help you debug, I summarize my setup. My tests are of mixed results. Sometimes it works fine, sometimes not. Currently .... after restarting, I couldn't setup the tunnel: doing another try right after it: this could be related to a bad and probably very cheap NAT implementation on the local DSL modem, but as I said, my results vary. Edit: as I was so carelessly to post my full command line here, I had to change the secret ¯_(ツ)_/¯ |
|
Update: |
|
Ok, any chance you could share your server details with me maybe over a secure private chat. I try your server and we rule out the possibility that it’s due to my server setup. Now I’m questioning each and every step I did… 🤦♂️ |
I’m hosting iodine at my place, on my nas. Just my ISP in between. |
I meant what upstream dns provider do you use on your client machine? |
|
Ah sorry. I’m using a variety but I feel like using iodine itself is preferable if it works. Let’s say, my public IP address is 1.2.3.4, I try to use 1.2.3.4 as upstream DNS first. If the network does not allow it, then I move to the standard provided by DHCP, then I try the usual ones, 8.8.8.8 (google) or 1.1.1.1. But the RAW tunnel should not care much about this, as only a few queries are done to authenticate and get the server IP (and those work). |
|
I can agree, we should have raw mode working reliably first. I can recommend to anybody having problems getting iodine to run, please watch your debug output, you might notice your questions are received, but the answer never reaches your client because of NAT issues as in my case. Having said raw mode first, I still tested without raw (-r) with the following public recursors: |
|
@m0yellow do you have any news? |
|
As we have not currently made any progress, I was wondering if there are any settings I can change to make non-raw connections more efficient? I am mainly using PurpleHaze for the client and a Digital Ocean VM for the server. |
|
I started looking around. In the MacOS console when running |
|
@Mrc527 I currently do not get raw mode to work with NAT. |
Hello,
am I the only one who cannot get raw mode working on macOS / iOS?
Same setup, a linux and even a windows box can connect to raw socket but macos says test failed and goes through DNS queries (with a huge performance penalty).
It's curious to see that a linux VM running on my macbook can make the socket connection, while once again the host cannot.
Is there any limitation in place by Apple or maybe it's just about setting up the socket in a different way?
I'm sorry I cannot help you with the code but I can be a tester here 😁
The text was updated successfully, but these errors were encountered: