Subject: Re: Tutorial: Build a one-click Windows custom SOCKS5 proxy client using freeware

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 <process>:<hosts>:<ports>:<protocol>:<action>
# 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.
# OpenVPN kept looping "Waiting for TUN/TAP interface to come up"
# v1p9 20251201
# Combined both TCP/UDP cases in a single rules.txt file by
# explicitly allowing UDP traffic from OpenVPN to go DIRECT,
# while still proxying TCP 443 through Psiphon
# Now TCP tunnel traffic is proxied through Psiphon
# While UDP tunnel traffic bypasses ProxyBridge (DIRECT)
# And TAP setup traffic (DHCP, ARP, route injection) is always DIRECT so
# OpenVPN can bring the interface up in time given ProxyBridge delays.
# v2p0 20251201
# The rules bypassed ProxyBridge, but the TAP adapter still failed DHCP.
# Windows gave it a fallback 169.254.x.x address, so OpenVPN reported
# "Completed With Errors." For UDP VPNGate configs to work, they must run
# DIRECT without Psiphon, and the network must allow the TAP adapter
# to obtain a proper 10.x.x.x lease from the VPN server.
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

--proxy socks5://127.0.0.1:1080 # Psiphon local SOCKS5 listener
# --proxy socks5://127.0.0.1:9150 # Tor Browser SOCKS5 listener (optional)

# Applications that should always use the proxy
--rule telegram.exe:*:*:TCP:PROXY
--rule MemoryHogs.exe:*:*:TCP:PROXY
--rule dialog.exe:*:*:TCP:PROXY

# Block QUIC/HTTP3 globally
--rule *:*:443:UDP:BLOCK

# Brave rules
--rule brave.exe:*:*:TCP:PROXY
--rule brave.exe:*:443:UDP:BLOCK
--rule BraveUpdate.exe:*:*:TCP:BLOCK
--rule brave.exe:*:5228:TCP:BLOCK
--rule brave.exe:*:53:UDP:BLOCK

# Chromium rules
--rule chrome.exe:*:*:TCP:PROXY
--rule chrome.exe:*:443:UDP:BLOCK
--rule chrome.exe:*:5228:TCP:BLOCK
--rule chrome.exe:*:53:UDP:BLOCK

# Firefox rules
--rule firefox.exe:*:*:TCP:PROXY
--rule firefox.exe:*:443:UDP:BLOCK

# Block telemetry and unwanted processes
--rule OneDrive.exe:*:*:TCP:BLOCK
--rule CompatTelRunner.exe:*:*:TCP:BLOCK
--rule SearchApp.exe:*:*:TCP:BLOCK

# Core system processes bypass proxy
--rule svchost.exe:*:*:TCP:DIRECT
--rule services.exe:*:*:TCP:DIRECT
--rule system:*:*:TCP:DIRECT

# Utility
--rule curl.exe:*:*:TCP:PROXY

# DNS and TAP setup bypass
--rule svchost.exe:*:53:UDP:DIRECT
--rule svchost.exe:*:67,68:UDP:DIRECT
--rule svchost.exe:*:*:UDP:DIRECT
--rule system:*:*:UDP:DIRECT
--rule route.exe:*:*:TCP:DIRECT
--rule route.exe:*:*:UDP:DIRECT

# OpenVPN rules
--rule openvpn.exe:*:443:TCP:PROXY # TCP tunnel proxied through Psiphon
--rule openvpn.exe:*:*:UDP:DIRECT # UDP tunnel bypasses ProxyBridge
# NOTE: For UDP OpenVPN configs to work, they must run DIRECT without Psiphon,
# and the network must allow the TAP adapter to obtain a proper 10.x.x.x lease.
# Otherwise OpenVPN will report "Initialization Sequence Completed With Errors"
# and the TAP adapter will fall back to a 169.254.x.x APIPA address.

# Log level
--verbose 3

# end of C:\app\network\proxy\proxybridge\rules.txt
--
The point of Usenet is for smart people to help each other & for results
to be archived so that anyone can access our immense tribal knowledge.

--- PyGate Linux v1.5.1
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)