XPost: alt.comp.os.windows-10, alt.comp.os.windows-11   
   From: marianjones@helpfulpeople.com   
      
   HUGE UPDATE:   
      
   I finally fixed a huge problem in that I could never (until now) get VPN to   
   work *last* in the chain (i.e., psiphon + proxybridge + VPN) even as VPN   
   worked fine *first* in the chain (i.e., VPN + psiphon + proxybridge).   
      
   MULTIPLE problems needed to be identified:   
   1. Windows TAP adapter race condition ("Waiting for TUN/TAP interface to come   
   up")   
   2. Psiphon SOCKS5 proxy lacks UDP ASSOCIATE   
   3. TAP adapter DHCP failures -> APIPA fallback   
   4. Free VPN server config variability (static IP vs DHCP push)   
      
   After solving those problems, finally, VPN works fine on Windows   
   whether it's the first or the last in the encryption chain of events.   
      
   However, initially only two issues seemed to show up which had to be solved:   
   1. Windows is too slow so we get "Waiting for TUN/TAP interface to come up"   
   2. The Psiphon SOCKS5 proxy supports TCP ASSOCIATE but not UDP ASSOCIATE   
      
   Given that, TCP VPN configs "should" have worked, even as UDP wouldn't work   
   when VPN was last in the chain (i.e., after ProxyBridge was initiated).   
      
   What took a while to identify was WHY both UDP & TCP OpenVPN configs failed   
   (where the VPN error for TCP was DIFFERENT than the error for UDP configs).   
    TCP: "Waiting for TUN/TAP interface to come up"   
    UDP: AIPA fallback "Initialization Sequence Completed With Errors"   
      
   What first needed to be modified in order for both TCP & UDP configs to   
   work (whether or not VPN was first or last in the encryption chain) was   
   each OpenVPN config file needed to tell OpenVPN.exe to employ adaptive   
   commands to set up the TAP interface, and to wait longer before route   
   injection occurs.   
    # Adaptively choose how Windows OpenVPN configures the TAP adapter   
      ip-win32 adaptive   
    # Give Windows 10 seconds longer before route injection begins   
      route-delay 10   
      
   In addition to that TAP adapter setup race with route injection, there is   
   no way around the fact that Psiphon's SOCKS5 proxy doesn't support UDP.   
      
   So the Psiphon rules.txt file needed to be modified extensively.   
      
   The rules.txt file had to be modified so that OpenVPN traffic   
   was handled correctly depending on protocol type. Before, both   
   TCP and UDP configs failed when VPN was placed last in the chain.   
      
   Here are the key changes between version 1p7 & 2p0 rules.txt:   
   a. Explicitly route OpenVPN.exe TCP traffic through Psiphon   
      Rule added:   
        openvpn.exe:*:443:TCP -> PROXY   
      This ensures that TCP VPN configs are proxied through   
        Psiphon's SOCKS5 tunnel.   
      
   b. Explicitly allow OpenVPN.exe UDP traffic to bypass Psiphon   
      Rule added:   
        openvpn.exe:*:*:UDP -> DIRECT   
      Because Psiphon's SOCKS5 proxy does not support UDP ASSOCIATE,   
        UDP VPN configs must go direct to the server.   
      
   c. Allow TAP/DHCP/DNS setup traffic to go DIRECT   
      Rules added:   
        svchost.exe:*:53:UDP -> DIRECT   
        svchost.exe:*:67,68:UDP -> DIRECT   
        system:*:*:UDP -> DIRECT   
      These ensure that Windows can perform DNS lookups and DHCP   
        lease negotiation for the TAP adapter without being blocked   
        or forced through Psiphon.   
      
   d. Block unwanted UDP traffic from browsers and apps   
      Rules added such as:   
        chrome.exe:*:443:UDP -> BLOCK   
        firefox.exe:*:443:UDP -> BLOCK   
        brave.exe:*:443:UDP -> BLOCK   
      This prevents browsers from leaking QUIC/UDP traffic outside   
        the encrypted chain.   
      
   e. Maintain TCP direct access for system processes   
      Rules like:   
        svchost.exe:*:*:TCP -> DIRECT   
        services.exe:*:*:TCP -> DIRECT   
        system:*:*:TCP -> DIRECT   
      These allow Windows core services to function normally while   
        keeping user applications proxied.   
      
   Here is the current status as of version 2p0 of the rules.txt file:   
   1. TCP OpenVPN configs now work when VPN is last in the chain,   
      because their traffic is correctly proxied through Psiphon.   
   2. UDP OpenVPN configs now work when VPN is last in the chain,   
      because their traffic bypasses Psiphon and goes direct.   
   3. TAP adapter setup traffic (DNS, DHCP) is allowed direct, so   
      Windows no longer fails with APIPA addresses.   
   4. Browser UDP traffic (QUIC) is blocked, preventing leaks.   
      
   The critical changes in rules.txt were:   
   1. Split handling of OpenVPN.exe traffic: TCP -> PROXY, UDP -> DIRECT.   
   2. Allow svchost/system UDP traffic direct for TAP setup.   
   3. Block browser UDP traffic to prevent leaks.   
   4. Keep system TCP traffic direct for stability.   
      
   Together with the OpenVPN config additions   
   (ip-win32 adaptive + route-delay 10), these rules fixed the   
   longstanding problem which had prevented VPN from being used after   
   ProxyBridge. Now VPN works reliably whether it is first or last in the   
   encryption chain.   
      
   Here is the version 2p0 of the rules.txt file to donate to the team.   
     # C:\app\network\proxy\proxybridge\rules.txt v1p0 20251023   
     # This is version 2p0   
     # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #   
     # Load this into ProxyBridge using the pb.bat script.   
     # Syntax: --rule ::::   
     # Rules are case insensitive, # indicates comments, blank lines ignored.   
     # v1p1 20251023   
     #  Added useful examples of block, direct & proxy for others to benefit   
     #  Added usable inline comments (requires pb.bat v2p6 or higher to handle)   
     # v1p2 20251023   
     #  Added usability explanations of dns complexity & QUIC/HTTPS3 issues.   
     #  Added UDP block to handle Brave using experimental protocols above.   
     # v1p3 20251023   
     #  Added clarification that TCP & UDP rules are not overridden   
     # v1p4 20251024   
     #  Added Tor SOCKS5 proxy server (in addition to Psiphon's)   
     # v1p5 20251024   
     #  Note that Tor cannot proxy UDP, so I had to add specific rules for that.   
     # v1p6 20251025   
     #  Added Chrome, Brave, Edge & FF browser rules due to phoning home.   
     # v1p7 20251024   
     #  Fixed error that Psiphon doesn't support UDP ASSOCIATE   
     #  This is to avoid proxying UDP (Psiphon doesn't support UDP ASSOCIATE)   
     #  Cleaned up DNS section because DNS via proxy is enabled by default   
     # v1p8 20251130   
     #  Added DIRECT rules for svchost.exe, route.exe, and system UDP.   
     #  So that TAP setup traffic bypasses ProxyBridge.   
     #  Tunnel traffic (openvpn.exe on TCP 443) still goes through Psiphon.   
     #  This separation allowed DHCP and ARP to succeed but Windows was slow   
     #  to set up the tunnel until I added two directives to TCP config files.   
     #   ip-win32 adaptive   
     #   route-delay = 10   
     #  Remaining issue:   
     #  Even with bypasses, Windows was slow to mark TAP up.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)