5 ms·

I use WireGuard (including WireGuard iOS) every day in Shanghai. It’s mostly fast and performant but nothing escapes the occasional “drop all UDP to your endpoi

I use WireGuard (including WireGuard iOS) every day in Shanghai. It’s mostly fast and performant but nothing escapes the occasional “drop all UDP to your endpoint”. Typically this manifests as windows of time (typically a few minutes) where no traffic to the VPN gets through. However, unlike an openVPN solution WireGuard recovers without having to bounce the tunnel or constantly reconnect. The GFW is not a monolithic entity though so be aware that performance and blocking characteristics can vary widely between cities, ISPs, and sometimes even between cell towers. VPN on demand features are on the iOS todo list. iOS supports the idea of making a VPN on demand for cellular or WiFi so it will be able to do what you want once that feature is merged.

NamTaf 8y ago
That's all good news. I'm aware that them blackholing all UDP traffic is always going to be an issue, but it's good to hear that Wireguard recovers gracefully. So, too, does Shadowsocks. Alternatives are always good, and having something more reflecting a true VPN rather than a SOCKS proxy will be useful once it makes it to Windows.
- cyphar 8y ago
  The really nice thing about WireGuard on Linux is that it acts like a regular network device and thus you can use iptables or network namespaces for free with it. Very clean and genius design that eradicates the need for any client support as well as removing the potential for leaking at the network device level (if you configure it in the "container" mode where you move your host network devices into an inaccessible network namespace and only provide wg0 on the host).
  - palunon 8y ago
    At lot of Linux VPN creates network interfaces (tap/tun), and support namespacing them - you can do the same thing with OpenVPN . The really nice thing is the full in-kernel implementation, and the lack of configurability.
    - cyphar 8y ago
      Right, sorry. I was comparing it to the shadow-socks project GP was referring to. (And the userspace WireGuard implementation uses TUN/TAP. In fact one of the rootless containers subprojects I've worked on is using TAP to allow for unprivileged network bridge emulation for rootless containers.)
- Fnoord 8y ago
  I was wondering if the behaviour of recovering gracefully or not gives away if its a (specific) VPN?
  - reaperhulk 8y ago
    VPN fingerprinting is simple in most cases. The preamble to stateful VPN session initiation is generally trivial to detect. WireGuard does not (at this time) attempt to obfuscate itself, but it’s more resistant to that particular type of detection since it does not do such negotiation. So yes, this behavior could be potentially used as a heuristic distinguisher for a deep packet inspection tool.
teknologist 8y ago
GFW probing is an interesting subject, and it's great that WireGuard can't really be probed (it does not respond at all to handshakes that do not use an expected key). An interesting related talk: https://www.youtube.com/watch?v=QBp6opkcxoc https://www.youtube.com/watch?v=QBp6opkcxoc
bogomipz 8y ago
>"It’s mostly fast and performant but nothing escapes the occasional “drop all UDP to your endpoint”." Does the GFW start dropping UDP packets between two endpoints beyond a certain threshold? Is WG generating that message or something else?
- NamTaf 8y ago
  Who knows? The behaviour I've observed suggests it may, but it's such an opaque system that it's hard to know. For example, there's suggestions that people have had better success if they're sending HTTP obfuscated data to an endpoint that also responds to HTTP requests. The implied situation here is that the GFW might see mass HTTP data to an IP, then try to query it itself. If it gets no results, it's probably not a HTTP server but rather obfuscated VPN data. It'll then choose to drop or aggressively throttle data to that IP. In my experience, I've had a VPN go more or less dead for a couple of days after about 30 days of use, before recovering after I leave it for a bit. In the interim, I can spin up a second IP and be fine on that one. That said, it was also to a streisand instance, which does respond to a HTTP(S) request on the IP, so maybe this heuristic wasn't my tell. So maybe I was instead picked up because I globally routed all traffic directly at one IP and never went outside that. Others have suggested success on keeping VPNs active longer if they occasionally browse directly to random sites, so that the GFW sees their IP accessing a multitude of sites and therefore doesn't look as much like all data is going to a single IP. I've not had any noticeable anecdata to go either way on this. The reality is, no one trying to jump the GFW truly knows how the GFW does its DPI. Moreover, as a reply said to my original post, the GFW isn't a single entity and differs across cities and regions in China.
  - bogomipz 8y ago
    Interesting. Thanks for the detail. Streisand is just WG implementation then?

NamTaf 8y ago

That's all good news. I'm aware that them blackholing all UDP traffic is always going to be an issue, but it's good to hear that Wireguard recovers gracefully. So, too, does Shadowsocks. Alternatives are always good, and having something more reflecting a true VPN rather than a SOCKS proxy will be useful once it makes it to Windows.

cyphar 8y ago
The really nice thing about WireGuard on Linux is that it acts like a regular network device and thus you can use iptables or network namespaces for free with it. Very clean and genius design that eradicates the need for any client support as well as removing the potential for leaking at the network device level (if you configure it in the "container" mode where you move your host network devices into an inaccessible network namespace and only provide wg0 on the host).
- palunon 8y ago
  At lot of Linux VPN creates network interfaces (tap/tun), and support namespacing them - you can do the same thing with OpenVPN . The really nice thing is the full in-kernel implementation, and the lack of configurability.
  - cyphar 8y ago
    Right, sorry. I was comparing it to the shadow-socks project GP was referring to. (And the userspace WireGuard implementation uses TUN/TAP. In fact one of the rootless containers subprojects I've worked on is using TAP to allow for unprivileged network bridge emulation for rootless containers.)
Fnoord 8y ago
I was wondering if the behaviour of recovering gracefully or not gives away if its a (specific) VPN?
- reaperhulk 8y ago
  VPN fingerprinting is simple in most cases. The preamble to stateful VPN session initiation is generally trivial to detect. WireGuard does not (at this time) attempt to obfuscate itself, but it’s more resistant to that particular type of detection since it does not do such negotiation. So yes, this behavior could be potentially used as a heuristic distinguisher for a deep packet inspection tool.

teknologist 8y ago

GFW probing is an interesting subject, and it's great that WireGuard can't really be probed (it does not respond at all to handshakes that do not use an expected key). An interesting related talk: https://www.youtube.com/watch?v=QBp6opkcxoc https://www.youtube.com/watch?v=QBp6opkcxoc

bogomipz 8y ago

>"It’s mostly fast and performant but nothing escapes the occasional “drop all UDP to your endpoint”." Does the GFW start dropping UDP packets between two endpoints beyond a certain threshold? Is WG generating that message or something else?

NamTaf 8y ago
Who knows? The behaviour I've observed suggests it may, but it's such an opaque system that it's hard to know. For example, there's suggestions that people have had better success if they're sending HTTP obfuscated data to an endpoint that also responds to HTTP requests. The implied situation here is that the GFW might see mass HTTP data to an IP, then try to query it itself. If it gets no results, it's probably not a HTTP server but rather obfuscated VPN data. It'll then choose to drop or aggressively throttle data to that IP. In my experience, I've had a VPN go more or less dead for a couple of days after about 30 days of use, before recovering after I leave it for a bit. In the interim, I can spin up a second IP and be fine on that one. That said, it was also to a streisand instance, which does respond to a HTTP(S) request on the IP, so maybe this heuristic wasn't my tell. So maybe I was instead picked up because I globally routed all traffic directly at one IP and never went outside that. Others have suggested success on keeping VPNs active longer if they occasionally browse directly to random sites, so that the GFW sees their IP accessing a multitude of sites and therefore doesn't look as much like all data is going to a single IP. I've not had any noticeable anecdata to go either way on this. The reality is, no one trying to jump the GFW truly knows how the GFW does its DPI. Moreover, as a reply said to my original post, the GFW isn't a single entity and differs across cities and regions in China.
- bogomipz 8y ago
  Interesting. Thanks for the detail. Streisand is just WG implementation then?