Dynamic UDP port blocking

[msshn]

I think there is some UDP port blocking in Iran not just by IP but also by the software used.
Here's the situation:
I have 2 vps server from the same company. one in the US and another one in Europe, we call these US1 and EU1 servers. on the US1 server i can use UDP based proxies like hysteria without issue but on the EU1 one no UDP based proxies can connect. at first I suspected the UDP port on the EU1 server were all blocked based on IP, But by using Ncat i opened a tunnel from my home PC to the EU1 server and UDP packets delivered whitout any issue!! Any thing I typed on my PC show up one the vps server instantly. then i tested the EU1 and US1 servers UDP connection with each other and they could send and receive UDP packets fine. Obviously, UDP connection between me and US1 server also works both with Ncat and Hysteria.
At this point, I suspected maybe something is wrong with EU1 server so i bought 2 new VPS servers. one from EU and one from US. we call these US2 and EU2 servers. Testing with Ncat showed this results :

RESULTS
The VPS and Hysteria configs on all servers are all the same.
All 4 Servers can send/receive UDP to/from each other.
I can send UDP packets with Ncat to all 4 servers on differnt ports.
Using Tcpdump on servers, no UDP packet sent from client by hysteria to EU1, EU2 and US2 get received by the server.
Wireshark on the client shows UDP packets get sent by the client.
I can only stablish Hysteria UDP proxy to US1 Server.
at the same time other UDP based proxies like Tuic Could'nt connect on any server.

MY CONCLUSION
The protocol itself (at least Hysteria) is not blocked.
The UDP ports of dirty IPs (in this case EU1,EU2,US2) are not blocked completely but somewhat partly. Maybe UDP ports are blocked but with some whitelist rules, for example allow well known tools like Ncat, socat , etc. to go through. I'm not sure if it's technically possible to do this. (Does these tools leave any fingerprint or something?)

[wkrp]

Thanks for this information. A question to help diagnose what's going on:

When you run Hysteria and Hysteria sends UDP packets to a certain port on the proxy server, do unrelated UDP packets (non-Hysteria) to the same port at the same time also get blocked? Let's say that Hysteria is sending to port 5555. Try running this Nping command:

nping --udp --count 0 --dest-port 5555 --data-string "test hello" EU1

You won't get any UDP responses from the client, but with tcpdump on the server (tcpdump -n -X udp and dst port 5555) you should be able to see the packets arriving. Now start Hysteria on the client. You have said that the Hysteria packets do not arrive. Do the Nping packets also stop (the ones that are marked with "test hello")?

This experiment is designed to distinguish two possibilities. One possibility is that the firewall inspects every UDP packet, probably looking for a distinctive fingerprint that indicates Hysteria, and then drops those packets (and only those packets). Another possibility is that the firewall detects Hysteria somehow, and then blocks all UDP packets to the same IP or the same IP:port for a short time. See the notes about "residual censorship" at #43 (China) and the note about blocking persisting for 60 seconds from #49 (Iran, but about TCP in that case).

[poorp]

@wkrp I don't know how to use ncat, nping or tcpdump but I tried iperf3 with and without a hysteria connection (I turned on my hysteria node in sagernet and it doesn't acutally connect but I think it keeps sending packets while it's on).
Without the hysteria trying to connect, I can see iperf working (with the -u tag) but it has about 50% packet loss and with the hysteria it's the same.

[Azadzadeh]

which networks? which datacenter? are eu1, eu2, us1 and us2 from the same datacenter?

I believe they just completely blocked UDP on mobile networks...

do this socat test from your pc to us1 in mobile network. does it work?

[msshn]

@wkrp I did tests you said. The server did nor receive any packets with nping command.
I couldn't test the same thing with ncat because when hysteria was listening on port 10000, ncat couldn't bind to the same port so we can test them simultaneously.
here is screen shots of US2 Tests with hysteria running on port 10000 which doesn't connect:
ScreenShot 1
ScreenShot 2

here is screen shots of US1 Tests with hysteria running on port 20000 and works fine:
ScreenShot 1
ScreenShot 2

note that both servers are running ubuntu 22.04 and firewalls both on client and server are disabled.

These VPSs are rather cheap and there is a high probability their IPs already is dirty and I'm probably just got lucky with US1

@Azadzadeh
US1 and EU1 are from BuyVM and US2 and EU2 are from Racknerd
I have tested US1 Hysteria on mobile networks such as Irancell, MCI, Shatel Mobile and it worked fine.
I also tested on Asiatech and Shatel ADSL/TD-LTE and no issue there either.
I have also managed to run tuic on US1 as well and it worked fine on all networks too.

[msshn]

@wkrp I should also add that i ran hysteria on US2 (Which couldn't connect) and while it was trying to connect, I sent packets with ncat to the same hysteria port and listened with tcpdump (which was already listening for hysteria packets). Ncat packets received but hysteria packets didn't.

[poorp]

... Ncat packets received but hysteria packets didn't.

If the problem is indeed the packages being blocked because they are/look like hysteria (or any other proxy or VPN), It can't be that hard to circumvent. "Cloak" or "swgp-go" are a couple examples that could possibly help. "UDPspeeder" might be one too.

[msshn]

@poorp the problem can't be just because those packets are or look like hysteria, because in that case the other connection (US1) should get blocked too.
And it's not just hysteria, the exact same situation is happening with Tuic as well.

[poorp]

@msshn in that case, they are probably limiting ip ranges of popular VPS providers which makes this all the more difficult and practically throws UDP out the window.

[Azadzadeh]

@msshn

thanks. that is a very good data point. these providers are not famous.

my recent experience and this info means most of our problems are related to "dirty" IP and IP-ranges. meaning if you are using a secure and recent circumvention method but are not able to connect, you have to doubt your IP first then the proxy tools...(i'm only talking about TCP, we should just forget about UDP in iran)

also if you have UDP going, best option in terms of performance and security would be hysteria not wg or tuic.

TUIC's goal is to minimize the handshake latency as much as possible

I don't think circumventing gfw is in that project's scope. see here: tuic-protocol/tuic#119 (comment)

[wkrp]

I should also add that i ran hysteria on US2 (Which couldn't connect) and while it was trying to connect, I sent packets with ncat to the same hysteria port and listened with tcpdump (which was already listening for hysteria packets). Ncat packets received but hysteria packets didn't.

Thank you, this is the information I wanted. It looks like dynamic protocol detection, not IP or IP:port blocking with time-based residual blocking.

the problem can't be just because those packets are or look like hysteria, because in that case the other connection (US1) should get blocked too.
And it's not just hysteria, the exact same situation is happening with Tuic as well.

Don't assume that the censorship rules are the same always. As @poorp suggests, it may depend on the destination address in addition to features of the protocol.

I don't know the Hysteria protocol, but it may have something to do with lages packet sizes. (length 1268 in Hysteria-us-E.jpg.) Check if there is an option to limit packet sizes, and try lowering the settings to 100 or 200 bytes.

The server did not receive any packets with nping command. [But the server did receive packets with ncat --udp.]

This is an interesting result. The packets produced by Nping should be mostly the same as the packets produced by Ncat. The most likely explanation is that Nping's default UDP source port of 53 is causing the packets to be blocked by a different blocking rule. Try adding something like --source-port 12345 to the Nping command.

[msshn]

@wkrp
changing the Nping source port did the trick and all Nping packets recieved on the server by changing the source port.

However starting from yesterday even US1 server can not connect via any UDP proxy protocols like Hysteria or Tuic on any port. Also no Hysteria packets any longer get recieved by the server on any port.
This is exactly what happened to EU1 Server. on that server Hysteria worked for about 3 days then get blocked, but this US1 Server worked for about a month.
So I think even if you manage to find a clean IP, UDP is just a matter of time before getting blocked and therefore in current situation of Iran, is completely useless.

[arandomgstring]

@msshn

If you like to use UDP over TCP (because of speed, latency, etc) imo you should be using QUIC protocol and nothing else. Seriously, I mean it. You can do so by using xray. I am starting to see more and more websites (Even Iranian ones to my surprise) use this protocol. Not to mention almost all Google Services started using it. Therefore, I think there is a lower chance of being blocked in a month or two.

[tobyxdd]

@arandomgstring

you should be using QUIC protocol and nothing else. Seriously, I mean it.

Developer of hysteria here. The two UDP protocols (hysteria & tuic) the poster has tried are both QUIC-based, so I'm not sure what you are trying to say.

@msshn

Based on the information I think Iranian ISPs may be blocking all "unknown" UDP protocols, including non-HTTP/3 QUIC. The process may not be real-time and will only be triggered after a certain amount of traffic, which might be why some servers worked for a while.

If possible there are two experiments you could do:

1. Disable hysteria's obfs, change alpn to h3, and run the server on UDP port 443. Assuming HTTP/3 is in the protocol "whitelist" and that Iranian ISPs have not implemented active probing techniques to detect if a QUIC server is actually a web server, this might be enough to mislead the firewall into thinking you are just visiting an HTTP/3 website.

2. Try faketcp protocol (requires both the client & server to be running on Linux). All middleboxes will perceive it as TCP, bypassing all restrictions on UDP.

[tobyxdd]

I'm also exploring making a proxy protocol based entirely on HTTP/3. A hysteria server would then appear to be an unremarkable HTTP/3 web server (that can be configured to act as a reverse proxy for a website) but would function as a proxy when the correct credentials are provided.

[poorp]

@tobyxdd
Hi Toby,
I will try your suggestions and let you know asap.
Meanwhile, here is a bit more information for you that might help you understand the situation better and if you do, please let us know what's going on:
I haven't tried hysteria's faketcp but I have tried a udp tunnel that converts udp to faketcp and while it works with some servers and some ports, it does not work on most servers.
I have also tried to test many ports on some servers with iperf3. A few servers connect to a few others on a few tcp ports some times but the same servers don't see anything other times and some servers just show nothing at all!
As far as UDP goes, it's mostly the same scenario and even the tests that are kind of successful show about 50% packet loss. Usually the download (from foreign server to the domestic one) is fine and upload fails.
As a side note I am also availabe if you want to test anything and I can give you my very safe and very anonymous contact info. We have a small group chat with a bunch of people trying to figure out ways to circumvent in Telegram and it would mean the world to me if I could be in contact with you.

[tobyxdd]

@poorp Yes, you can reach me on Telegram. Just send me your contact info to my email address (check my GitHub profile)

[arandomgstring]

@tobyxdd
I apologize, I thought that Hysetria simply imitates QUIC protocol without using actual TLS certificates (just like how newer versions of shadowsocks imitate https without actually doing the handshake). My thought process went like this: Quic http3 encrypt and protect data by itself (with tls against DPI, MITM, etc) therefore there is no need for additional password (obfs), however, Hysteria uses a password (obfs) to encrypt data, therefore it doesn't use real TLS. After checking document, I understood I was wrong, though I am still not quite sure why exactly obfs is needed.

@poorp & @tobyxdd
As for state of QUIC in Iran, I am afraid that it is completely blocked, as the client doesn't receive Server Hello at all. I checked quite a few websites such as google.com (which is whitelisted) and cloudflare.com (whitelisted also) and dozen of others. What I see in Wireshark, is that client sends client hello, but never receives Quic server hello, therefore automatically the connection is downgraded to simple tcp https TLS1.2 or TLS1.3. One possibility was that this protocol (QUIC) is not supported by ISPs themselves, but I checked an Iranian website mihanwebhost.com and observed that the client does receive QUIC server hello and can maintain connection on QUIC without downgrading. A simple conclusion is that QUIC can only be served on Iranian IPs as of now. Hopefully someone can confirm, or reject this hypothesis.

[tobyxdd]

@arandomgstring

Quic http3 encrypt and protect data by itself

This is of course true but QUIC doesn't hide the fact that it's QUIC. One can easily tell if a connection is using QUIC (by its TLS handshakes & packet headers). The purpose of obfs is to obfuscate these so that it appears to be some unknown random UDP traffic instead.

[poorp]

It's true, we tested it.

…

On Mon, Jan 9, 2023, 20:50 arandomgstring ***@***.***> wrote: @tobyxdd <https://github.com/tobyxdd> I apologize, I thought that Hysetria simply imitates QUIC protocol without using actual TLS certificates (just like how newer versions of shadowsocks imitate https without actually doing the handshake). My thought process went like this: Quic http3 encrypt and protect data by itself (with tls against DPI, MITM, etc) therefore there is no need for additional password (obfs), however, Hysteria uses a password (obfs) to encrypt data, therefore it doesn't use real TLS. After checking document, I understood I was wrong, though I am still not quite sure why exactly obfs is needed. @poorp <https://github.com/poorp> & @tobyxdd <https://github.com/tobyxdd> As for state of QUIC in Iran, I am afraid that it is completely blocked, as the client doesn't receive Server Hello at all. I checked quite a few websites such as google.com (which is whitelisted) and cloudflare.com (whitelisted also) and dozen of others. What I see in Wireshark, is that client sends client hello, but never receives Quic server hello, therefore automatically the connection is downgraded to simple tcp https TLS1.2 or TLS1.3. One possibility was that this protocol (QUIC) is not supported by ISPs themselves, but I checked an Iranian website mihanwebhost.com and observed that the client does receive QUIC server hello and can maintain connection on QUIC without downgrading. *A simple conclusion is that QUIC can only be served on Iranian IPs as of now. Hopefully someone can confirm, or reject this hypothesis.* — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3VHC2GWJ2UU2R37QBG3O3TWRRCFTANCNFSM6AAAAAATHUDZ3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[arandomgstring]

@poorp
Iranian censors are genius. They block new technologies, because it gives them headache later on. How wonderful indeed. I guess the only way to circumvent this issue is IP spoofing #159, because from what I can see, this blockage is IP based. Unlike TCP based connections, IP spoofing for pure UDP should be easy. I guess a few line of IPtable rules will suffice for such purpose, but they should be dynamically generated each time that user tries to connect to server, because user's IP is dynamic. With IP spoofing, a foreign VPS server can pretend that it is an Iranian VPS server, therefore, it should bypass UDP restrictions easily. Something as simple as sudo iptables -t nat -A POSTROUTING -p udp -j SNAT --to-source an Iranian IP -d user's dynamic IP might be more than enough for pure UDP that doesn't do acknowledgements.

I guess It won't work with hysteria, since Its TLS handshake won't be completed. Unless someone write a simple code that add IPtable rule immediately after the handshake. I will explain what can be done, but I cannot test it myself:

@tobyxdd

Since they are blocking QUIC from foreign IPs, do you think something like IP spoofing is doable for hysteria protocol (in theory at least)? I am proposing this to make Hysteria work in Iran. So it goes like this: we send packets to VPS server via ssh (or any other unrestricted protocol in Iran), and receive QUIC packets from the foreign VPS server with "spoofed Iranian IP address" (so that it looks like we are receiving QUIC packets from Iranian IP address, not a foreign VPS server which causes blockage).

On client side:

1. First, do QUIC handshake inside SSH (or alternatively tcp TLS (https)) proxy which is not blocked.

For this purpose we can open a ssh tunnel like this
ssh - L localport:foreign VPS IP: foreign UDP port of VPS user@foreign VPS IP -p ssh port
afterward user should add VPS domain 127.0.0.1 in OS host file, and in Hysteria instead of writing domain:UDP port, user should write domain:local port, so that every time Hysteria wants to send udp packets to domain:udp port, it will send them to 127.0.0.1:localport, which in turn transforms them to ssh packet and sends them to ssh port, which is not blocked.

2. Client receives QUIC packets from a "spoofed Iranian IP address", but client should not respond those packets back to "spoofed Iranian IP address", instead it should send them to foreign VPS IP via ssh (or whatever that's not blocked).

On Linux, we can simply write
sudo iptables -t nat -A PREROUTING -d spoofed Iranian IP address -j DNAT --to-destination 127.0.0.1:localport
Doing so make linux to send "respond packets" to Foreign VPS server via SSH, as desired, and that's it. On Windows though, it cannot be done, unless someone goes and write a low level C code with Windriver or WF which is a pain. We can do something else though, we can completely block "spoofed Iranian IP address" with firewall, so that we don't send any "respond packets" back. But it might cause some problems on Hysteria protocol on server side (I guess?) which I am not aware of.

On server side:

1. When QUIC handshake is done from Hysteria port, take user IP and add the IPtable rule for IP spoofing by

sudo iptables -t nat -A POSTROUTING -p udp -j SNAT --to-source spoofed Iranian IP address -d user's dynamic IP

2. Honestly, that is it. However, Because I think Windows Client causes issues for Hysteria protocol because it doesn't send "respond packets", here, in server, we might need to modify Hysteria protocol such that it doesn't "wait" for respond packets optionally. I don't know if it is possible.

At any rate, on Linux systems its pretty straightforward. One IPtable rule + SSH connection and slight modification of hysteria and host file on client, and on server one IPtable suffices. I wonder if someone would test this.

[poorp]

@arandomgstring
Ok so I like the idea but I think there is a big problem with it:
First of all, we have come to realise that the problem with most forms of circumvention is upload (from Iran to foreign servers) I.E. vmess + ws works mostly fine but has a very limited upload bandwith around 1 Mbps. Even plain unobfuscated WireGuard sometimes works on some providers but you get upload speeds close to 0. Naive proxy works mostly fine on some ports but when you do a speedtest it has a good upload speed at first but it gets throttled pretty fast(and also disconnects). We also tested simply uploading files to popular file sharing services such as Google drive which is not blocked in Iran but it has the same behaviour and gets throttled after a few seconds. So they are limiting long uploads to foreign IPs from home and mobile connections.
Secondly, SSH (or ICMP) which we are actually using as two way tunnels right now and they work mostly fine, aren't very good options for the long term. While it certainly helps to have options for emergency situations, I don't think it would be hard for them to throtthle the "Prophet Muhammad" out of both icmp and SSH with the stupid logic that you don't need much bandwith for simple ping or SSH operarion and we don't care if all else related to these protocols breaks. Even if they don't throttle it they are still pretty obvious to the censor because they stand out. In fact they have already started restricting SSH strongly and icmp is in a very lossy state (can still be used for normal traffic but forget about any competetive gaming).
I think the real quest here is to find a reliable and strong way to send data out of this hellhole (I'm sorry but it's a fact) and once you do that, why not use the same thing to receive data as well?
I'm not familiar with the concept of ip spoofing but if there was a way to make a foreign VPS seem like a domestic one (we can use an actual domestic server for static ip) with minimal overhead without the need of another protocol to handle uploading, I think it would work great with WireGuard as well as Hysteria.

[arandomgstring]

@poorp

You see, each time you send a network packet out of your system, you do 2 things. First you write your own IP address on Source Address of your packet. Second, you write the IP address of your destination, for example google.com IP address. Changing destination address is pretty much useless, because your real destination doesn't receive any packets. Also note that network connections are usually bidirectional (i.e you send packets, and receive packets. Same goes for VPS).

Now, if you modify Source Address, it is as if you have sent a packet with correct destination address, but incorrect origin address. Therefore, your destination address does receive packet, but it doesn't have any idea where to reply. We can misuse this fact.

How? well, each time your Foreign VPS server send a packet to your client, it can modify its own Source Address to look like a domestic VPS server. Therefore, the client, ISP, etc all will assume that you are receiving packets from domestic servers and not Foreign VPS server, and let it to go through with any protocol, even QUIC which is blocked. So the packets that client receive and VPS sends are modifiable.

However, when your client want to send packet to your Foreign VPS server, it cannot modify either of source address or destination address. Why? Well if it modifies destination address, your foreign VPS server will receive nothing. On the other hand, if your client change source address, your VPS server still receive nothing (due to restriction of Iran on foreign IP address) or receive these packets very slowly, just like before.

My idea was that because most of time we are getting data from a VPS (download) and don't send much data to it (upload) with IP spoofing we can hide VPS usage significantly. Moreover, we can use any restricted protocol from wireguard to hysteria, which will offer better latency than TCP TLS based connections.

As for uploading speed, I assume FTP is another good option. It should work pretty well, because its very purpose is "uploading". If they throttle this, every single foreign hosted Iranian website out there will face a huge problem. I am not aware of any "FTP" tunnel though. If it exist, it should work. And if it doesn't, you can still upload huge file with normal FTP on your VPS and then send them from VPS to your destination.

[poorp]

Thanks for clarifying that. I think I need to clarify the fact that they have throttled upload to the point of Google drive and other file sharing services practically not working! Also, we are not talking very huge files here, I'm talking about the connection getting close to zero speeds on the upload after mere seconds! We have a serious upload issue and one that is causing problems with basically any usage. I also guess maybe behind the scenes of the VPN peovider that I said has plain unobfuscated WireGuard kinda working, the same IP spoofing idea has been implemented because I haven't seen any other WireGuard work at all and I've tried to host my own on many different IPs, it does not work. Also their upload speed is around 0.01 Mbps which makes sense in this case. With regards to hiding a lot of usage on the VPS I think this is a very brilliant idea and might solve a lot of our problems since they are overcharging the Moses out of foreign traffic right now and that's one of our big problems. I am really excited to try this method. Do you think it can be implemented with WireGuard with direct upload (hoping directly uploading WireGuard packets is going to be fine even at a very slow rate as a proof of concept)? And if so, will you please restate how I would go about testing this method (ELI5 perhaps? since I'm a newbie)

…

On Tue, Jan 10, 2023, 04:43 arandomgstring ***@***.***> wrote: @poorp <https://github.com/poorp> You see, each time you send a network packet out of your system, you do 2 things. First you write your own IP address on Source Address of your packet. Second, you write the IP address of your destination, for example google.com IP address. Changing destination address is pretty much useless, because your real destination doesn't receive any packets. Also note that network connections are usually bidirectional (i.e you send packets, and receive packets. Same goes for VPS). Now, if you modify Source Address, it is as if you have sent a packet with correct destination address, but incorrect origin address. Therefore, your destination address does receive packet, but it doesn't have any idea where to reply. We can misuse this fact. How? well, each time your Foreign VPS server send a packet to your client, it can modify its own Source Address to look like a domestic VPS server. Therefore, the client, ISP, etc all will assume that you are receiving packets from domestic servers and not Foreign VPS server, and let it to go through with any protocol, even QUIC which is blocked. So the packets that client receive and VPS sends are modifiable. However, when your client want to send packet to your Foreign VPS server, it cannot modify either of source address or destination address. Why? Well if it modifies destination address, your foreign VPS server will receive nothing. On the other hand, if your client change source address, your VPS server still receive nothing (due to restriction of Iran on foreign IP address) or receive these packets very slowly. My idea was that because most of time we are getting data from a VPS (download) and don't send much data to it (upload) with IP spoofing we can hide VPS usage significantly. Moreover, we can use any restricted protocol from wireguard to hysteria, which will offer better latency than TLS based connections. As for uploading speed, I assume FTP is another good option. It should work pretty well, because its very purpose is "uploading". If they throttle this, every single foreign hosted Iranian website out there will face a huge problem. I am not aware of any "FTP" tunnel though. If it exist, it should work. And if it doesn't, you can still upload huge file with normal FTP on your VPS and then send them from VPS to your destination. — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3VHC2DWWY2OT2CZN4NT3B3WRSZTLANCNFSM6AAAAAATHUDZ3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[msshn]

@tobyxdd
Hi and thank you for looking into this.
I have tried your suggestions with all possible configurations but unfortunately I was unable to make a connection. Also tried fake TCP both on a rooted android phone and a linux machine but also nothing.
I think QUICK is not completely blocked but very aggressively censored (maybe operating based on a whitelist mode instead of blacklist). We can see that with NaiveProxy which works in HTTPS mode but not in QUICK mode.

[arandomgstring]

@poorp

Let me make a suggestion first. You say a Wireguard VPN is working fine, right? Open it, and open Wireshark too. then in Wireshark, you might see 4 possibilities, based on what you see, we can make other Wireguard VPNs work.

1. You may see that you are sending and receiving UDP packets to and from a single IP address. In that case, they are not using IP spoofing, rather, it is very likely that they have implemented Wireguard VPN on an Iranian VPS, which is not subject to such blockages (and they have connected that Iranian VPS server to another VPN). To check this, simply check their server IP address in Wireshark, search it in Whois or something and see if their IP belongs to an Iranian company or not. If it was an Iranian company, then there you have it. That's how they have made it work. If it belonged to a foreign VPS provider, then you can buy VPS from that provider too. Perhaps it just so happened that they are not restricting IP range of some foreign VPS providers.

2. You might see you are sending udp packets to a foreign IP, while receiving udp packets from a domestic server. It's most likely the IP spoofing.

3. You may see you are sending TCP (for example ssh, or TLS, or simply TCP) packets and receiving UDP packets from a single IP address or maybe vice versa. This is asymmetric connection.

4. Finally, it is possible that in Wireshark, you will see you are sending TCP packets to a foreign IP, while receiving udp packets from a domestic IP. In this scenario, we have a mixture of asymmetric connection + IP spoofing. The suggestion I made about Hysteria above fall in this category.

Let me know the results.

[arandomgstring]

@msshn

I think QUICK is not completely blocked but very aggressively censored (maybe operating based on a whitelist mode instead of blacklist).

Just give me a single example of a foreign hosted website/service that uses QUIC and works fine in Iran.

[cross-hello]

Did the restrictions of Cloudflare lift? If so you may could use Cloudflare tunnel to transmit udp traffic. Jan 11, 2023 00:00:39 arandomgstring ***@***.***>:

…

@msshn[https://github.com/msshn] I think QUICK is not completely blocked but very aggressively censored (maybe operating based on a whitelist mode instead of blacklist). Just give me a single example of a foreign hosted website/service that use QUIC and works fine in Iran. — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYCFXOKOMVXLIYVJAZLWRWBSNANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYHNZESX7WQRXFL62FLWRWBSNA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDLHRK.gif]

[poorp]

@poorp

Let me make a suggestion first. You say a Wireguard VPN is working fine, right? Open it, and open Wireshark too. then in Wireshark, you might see 4 possibilities, based on what you see, we can make other Wireguard VPNs work.

1. You may see that you are sending and receiving UDP packets to and from a single IP address. In that case, they are not using IP spoofing, rather, it is very likely that they have implemented Wireguard VPN on an Iranian VPS, which is not subject to such blockages (and they have connected that Iranian VPS server to another VPN). To check this, simply check their server IP address in Wireshark, search it in Whois or something and see if their IP belongs to an Iranian company or not. If it was an Iranian company, then there you have it. That's how they have made it work. If it belonged to a foreign VPS provider, then you can buy VPS from that provider too. Perhaps it just so happened that they are not restricting IP range of some foreign VPS providers.

2. You might see you are sending udp packets to a foreign IP, while receiving udp packets from a domestic server. It's most likely the IP spoofing.

3. You may see you are sending TCP (for example ssh, or TLS, or simply TCP) packets and receiving UDP packets from a single IP address or maybe vice versa. This is asymmetric connection.

4. Finally, it is possible that in Wireshark, you will see you are sending TCP packets to a foreign IP, while receiving udp packets from a domestic IP. In this scenario, we have a mixture of asymmetric connection + IP spoofing. The suggestion I made about Hysteria above fall in this category.

Let me know the results.

I used WireShark and there was a single IP with WireGuard as protocol both sending and receiving, and no, as I expected, It wasn't an Iranian IP since Iran is under sanctions and this company (based in the USA) can't do business with Iranian providers. The IP belongs to M247 which to my knowledge does not accept crypto payments which are the only way we can pay (again, sanctions) and even if I could rent a VPS from them, it is probably going to get blacklisted or limited soon (just like what happened with Hetzner last week) so there is no point.
In conclusion: very SADGE. Can you adopt me please so I can immigrate?

[poorp]

Did the restrictions of Cloudflare lift? If so you may could use Cloudflare tunnel to transmit udp traffic. Jan 11, 2023 00:00:39 arandomgstring @.***>:
…
@msshn[https://github.com/msshn] I think QUICK is not completely blocked but very aggressively censored (maybe operating based on a whitelist mode instead of blacklist). Just give me a single example of a foreign hosted website/service that use QUIC and works fine in Iran. — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYCFXOKOMVXLIYVJAZLWRWBSNANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYHNZESX7WQRXFL62FLWRWBSNA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDLHRK.gif]

As a general rule, have this in mind: the Islamic Republic never lifts any restrictions, they just add more.

[cross-hello]

😅 could you use satellite internet? Jan 11, 2023 01:16:18 poorp ***@***.***>:

…

Did the restrictions of Cloudflare lift? If so you may could use Cloudflare tunnel to transmit udp traffic. Jan 11, 2023 00:00:39 arandomgstring /*@*/.***>: …[#] @msshn[https://github.com/msshn][https://github.com/msshn] I think QUICK is not completely blocked but very aggressively censored (maybe operating based on a whitelist mode instead of blacklist). Just give me a single example of a foreign hosted website/service that use QUIC and works fine in Iran. — Reply to this email directly, view it on GitHub[#181 (comment)[#181 (comment)]], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYCFXOKOMVXLIYVJAZLWRWBSNANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYHNZESX7WQRXFL62FLWRWBSNA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDLHRK.gif] As a general rule, have this in mind: the Islamic Republic never lifts any restrictions, they just add more. — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYDSFRDHFMVAPFLK7F3WRWKODANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYGGBYM7LQLN7AXH3MLWRWKODA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDRSEU.gif]

[poorp]

Sure, if only I had about 2000$ to buy the equipment and around 100$ per month for the subscription. The minimum wage in Iran is around 100$ a month (official rate) and the average income about 200$ per month (my estimate).

…

On Tue, Jan 10, 2023, 20:55 Nanyu ***@***.***> wrote: 😅 could you use satellite internet? Jan 11, 2023 01:16:18 poorp ***@***.***>: > Did the restrictions of Cloudflare lift? If so you may could use Cloudflare tunnel to transmit udp traffic. Jan 11, 2023 00:00:39 arandomgstring /*@*/.***>: > …[#] > @msshn[https://github.com/msshn][https://github.com/msshn] I think QUICK is not completely blocked but very aggressively censored (maybe operating based on a whitelist mode instead of blacklist). Just give me a single example of a foreign hosted website/service that use QUIC and works fine in Iran. — Reply to this email directly, view it on GitHub[#181 (comment)[ #181 (comment)]], or unsubscribe[ https://github.com/notifications/unsubscribe-auth/AKGBAYCFXOKOMVXLIYVJAZLWRWBSNANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you are subscribed to this thread.[Tracking image][ https://github.com/notifications/beacon/AKGBAYHNZESX7WQRXFL62FLWRWBSNA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDLHRK.gif ] > > As a general rule, have this in mind: the Islamic Republic never lifts any restrictions, they just add more. > > — > Reply to this email directly, view it on GitHub[ #181 (comment)], or unsubscribe[ https://github.com/notifications/unsubscribe-auth/AKGBAYDSFRDHFMVAPFLK7F3WRWKODANCNFSM6AAAAAATHUDZ3Q ]. > You are receiving this because you commented.[Tracking image][ https://github.com/notifications/beacon/AKGBAYGGBYM7LQLN7AXH3MLWRWKODA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDRSEU.gif ] > — Reply to this email directly, view it on GitHub <#181 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3VHC2AIU6OS6OBGMJ46YRTWRWLQFANCNFSM6AAAAAATHUDZ3Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cross-hello]

Sorry, we found starlink only free in Ukrine. Jan 11, 2023 01:29:56 poorp ***@***.***>:

…

Sure, if only I had about 2000$ to buy the equipment and around 100$ per month for the subscription. The minimum wage in Iran is around 100$ a month (official rate) and the average income about 200$ per month (my estimate). On Tue, Jan 10, 2023, 20:55 Nanyu ***@***.***> wrote: > 😅 could you use satellite internet? > > Jan 11, 2023 01:16:18 poorp ***@***.***>: > > > Did the restrictions of Cloudflare lift? If so you may could use > Cloudflare tunnel to transmit udp traffic. Jan 11, 2023 00:00:39 > arandomgstring /*@*/.***>: > > …[#] > > @msshn[https://github.com/msshn][https://github.com/msshn] I think > QUICK is not completely blocked but very aggressively censored (maybe > operating based on a whitelist mode instead of blacklist). Just give me a > single example of a foreign hosted website/service that use QUIC and works > fine in Iran. — Reply to this email directly, view it on GitHub[#181 > (comment)[ > #181 (comment)]], > or unsubscribe[ > https://github.com/notifications/unsubscribe-auth/AKGBAYCFXOKOMVXLIYVJAZLWRWBSNANCNFSM6AAAAAATHUDZ3Q]. > You are receiving this because you are subscribed to this thread.[Tracking > image][ > https://github.com/notifications/beacon/AKGBAYHNZESX7WQRXFL62FLWRWBSNA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDLHRK.gif > ] > > > > As a general rule, have this in mind: the Islamic Republic never lifts > any restrictions, they just add more. > > > > — > > Reply to this email directly, view it on GitHub[ > #181 (comment)], or > unsubscribe[ > https://github.com/notifications/unsubscribe-auth/AKGBAYDSFRDHFMVAPFLK7F3WRWKODANCNFSM6AAAAAATHUDZ3Q > ]. > > You are receiving this because you commented.[Tracking image][ > https://github.com/notifications/beacon/AKGBAYGGBYM7LQLN7AXH3MLWRWKODA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDRSEU.gif > ] > > > > — > Reply to this email directly, view it on GitHub > <#181 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/A3VHC2AIU6OS6OBGMJ46YRTWRWLQFANCNFSM6AAAAAATHUDZ3Q> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYGWRUT6ANFVSZU642TWRWMBHANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYG75HXT2X2TR5VW5SLWRWMBHA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDSTVA.gif]

[poorp]

Sorry, we found starlink only free in Ukrine. Jan 11, 2023 01:29:56 poorp @.>:
…
Sure, if only I had about 2000$ to buy the equipment and around 100$ per month for the subscription. The minimum wage in Iran is around 100$ a month (official rate) and the average income about 200$ per month (my estimate). On Tue, Jan 10, 2023, 20:55 Nanyu @.> wrote: > sweat_smile could you use satellite internet? > > Jan 11, 2023 01:16:18 poorp @.>: > > > Did the restrictions of Cloudflare lift? If so you may could use > Cloudflare tunnel to transmit udp traffic. Jan 11, 2023 00:00:39 > arandomgstring /@/.>: > > …[#] > > @msshn[[https://github.com/msshn]https://github.com/msshn] I think > QUICK is not completely blocked but very aggressively censored (maybe > operating based on a whitelist mode instead of blacklist). Just give me a > single example of a foreign hosted website/service that use QUIC and works > fine in Iran. — Reply to this email directly, view it on GitHub[#181 > (comment)[ > #181 (comment)]], > or unsubscribe[ > https://github.com/notifications/unsubscribe-auth/AKGBAYCFXOKOMVXLIYVJAZLWRWBSNANCNFSM6AAAAAATHUDZ3Q]. > You are receiving this because you are subscribed to this thread.[Tracking > image][ > https://github.com/notifications/beacon/AKGBAYHNZESX7WQRXFL62FLWRWBSNA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDLHRK.gif > ] > > > > As a general rule, have this in mind: the Islamic Republic never lifts > any restrictions, they just add more. > > > > — > > Reply to this email directly, view it on GitHub[ > #181 (comment)], or > unsubscribe[ > https://github.com/notifications/unsubscribe-auth/AKGBAYDSFRDHFMVAPFLK7F3WRWKODANCNFSM6AAAAAATHUDZ3Q > ]. > > You are receiving this because you commented.[Tracking image][ > https://github.com/notifications/beacon/AKGBAYGGBYM7LQLN7AXH3MLWRWKODA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDRSEU.gif > ] > > > > — > Reply to this email directly, view it on GitHub > <#181 (comment)>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/A3VHC2AIU6OS6OBGMJ46YRTWRWLQFANCNFSM6AAAAAATHUDZ3Q > . > You are receiving this because you were mentioned.Message ID: > @.*> > — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYGWRUT6ANFVSZU642TWRWMBHANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYG75HXT2X2TR5VW5SLWRWMBHA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDSTVA.gif]

Also, the government is claiming they can easily detect and find the receivers and also I'm pretty sure my neighbor is a government agent so he would probably sell me out in a matter of hours when I install that satellite receiver.

[cross-hello]

🥲 You are in serious adversity. Jan 11, 2023 01:34:34 poorp ***@***.***>:

…

Sorry, we found starlink only free in Ukrine. Jan 11, 2023 01:29:56 poorp /*@*/./*>: …[#] Sure, if only I had about 2000$ to buy the equipment and around 100$ per month for the subscription. The minimum wage in Iran is around 100$ a month (official rate) and the average income about 200$ per month (my estimate). On Tue, Jan 10, 2023, 20:55 Nanyu /*@*/.*/> wrote: > sweat_smile could you use satellite internet? > > Jan 11, 2023 01:16:18 poorp /*@*/.///>: > > > Did the restrictions of Cloudflare lift? If so you may could use > Cloudflare tunnel to transmit udp traffic. Jan 11, 2023 00:00:39 > arandomgstring //@//./*>: > > …[#] > > @msshn[https://github.com/msshn][[https://github.com/msshn]https://github.com/msshn[https://github.com/msshn%5D%5Bhttps://github.com/msshn]] I think > QUICK is not completely blocked but very aggressively censored (maybe > operating based on a whitelist mode instead of blacklist). Just give me a > single example of a foreign hosted website/service that use QUIC and works > fine in Iran. — Reply to this email directly, view it on GitHub[#181[#181] > (comment)[ > #181 (comment)[#181 (comment)]]], > or unsubscribe[ > https://github.com/notifications/unsubscribe-auth/AKGBAYCFXOKOMVXLIYVJAZLWRWBSNANCNFSM6AAAAAATHUDZ3Q]. > You are receiving this because you are subscribed to this thread.[Tracking > image][ > https://github.com/notifications/beacon/AKGBAYHNZESX7WQRXFL62FLWRWBSNA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDLHRK.gif > ] > > > > As a general rule, have this in mind: the Islamic Republic never lifts > any restrictions, they just add more. > > > > — > > Reply to this email directly, view it on GitHub[ > #181 (comment)[#181 (comment)]], or > unsubscribe[ > https://github.com/notifications/unsubscribe-auth/AKGBAYDSFRDHFMVAPFLK7F3WRWKODANCNFSM6AAAAAATHUDZ3Q > ]. > > You are receiving this because you commented.[Tracking image][ > https://github.com/notifications/beacon/AKGBAYGGBYM7LQLN7AXH3MLWRWKODA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDRSEU.gif > ] > > > > — > Reply to this email directly, view it on GitHub > <#181 (comment)[#181 (comment)]>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/A3VHC2AIU6OS6OBGMJ46YRTWRWLQFANCNFSM6AAAAAATHUDZ3Q > . > You are receiving this because you were mentioned.Message ID: > /*@*/.**> > — Reply to this email directly, view it on GitHub[#181 (comment)[#181 (comment)]], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYGWRUT6ANFVSZU642TWRWMBHANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYG75HXT2X2TR5VW5SLWRWMBHA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDSTVA.gif] Also, the government is claiming they can easily detect and find the receivers and also I'm pretty sure my neighbor is a government agent so he would probably sell me out in a matter of hours when I install that satellite receiver. — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYD25QQ2M5PPZN2EKMTWRWMSTANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYF6ISHAHLOK4K7ZWKTWRWMSTA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDS6ZU.gif]

[poorp]

@cross-hello Yes :( , Adopt maybe? :)

[cross-hello]

No, transform the suffering into motivation of leaving the country. If you insist, one day you must could leave. Jan 11, 2023 01:39:56 poorp ***@***.***>:

…

@cross-hello[https://github.com/cross-hello] Yes :( , Adopt maybe? :) — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYESFJBEF2UXKR7CHADWRWNGZANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYDWL4BA6GD6KQ65JFTWRWNGZA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSDTLEQ.gif]

[poorp]

No, transform the suffering into motivation of leaving the country. If you consist, one day you must could leave

Thanks for the motivation, I will.

[wkrp]

I'm also exploring making a proxy protocol based entirely on HTTP/3. A hysteria server would then appear to be an unremarkable HTTP/3 web server (that can be configured to act as a reverse proxy for a website) but would function as a proxy when the correct credentials are provided.

@tobyxdd thanks for your work. If you don't know of it yet, you should see the IETF MASQUE working group, which is all about standardizing proxy protocols over HTTP/3. This includes things like proxying UDP datagrams and IP packets. You can see the MASQUE meeting notes from the recent IETF 115 meeting. In my experience, some of the working group members are fairly well informed about censorship threat models. For example, in HTTP Transport Authentication, the text "This allows the server to accept authenticated clients without revealing that it supports or expects authentication for some resources" is about active probing attacks, like the ones considered in HTTPT.

[hunter-xue]

how about udp2raw

[cross-hello]

After seeing tcp, udp imitation, now finally meet ICMP masquerade. Feb 27, 2023 21:38:43 Hunter Xue ***@***.***>:

…

how about udp2raw[https://github.com/wangyu-/udp2raw] — Reply to this email directly, view it on GitHub[#181 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYHNIGIAS6TCMUHB52DWZSU6FANCNFSM6AAAAAATHUDZ3Q]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYELCECZE2XGBQMXQVLWZSU6FA5CNFSM6AAAAAATHUDZ3SWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSWGVSQM.gif]