When working with VPNs and multiple network interfaces, SSH connections can become unpredictable. The typical scenario:

C:\> ssh user@remote-server
# Connection hangs or fails when VPN is active

Windows prioritizes VPN routes over physical interfaces. Check your routing table with:

C:\> route print

You'll typically see your VPN gateway taking precedence for 0.0.0.0 (default route).

For PuTTY users, you can force interface binding:

1. Launch PuTTY
2. Load your saved session
3. Go to Connection > Data
4. Under "Logical name of local machine", enter your physical interface's IP
5. Save session

For more control, modify routes temporarily:

# Add specific route for your SSH server
C:\> route add remote.server.ip 255.255.255.255 physical.gateway.ip

# Delete when done
C:\> route delete remote.server.ip

Create a reusable script to handle interface switching:

$sshServer = "your.ssh.server"
$physicalInterface = (Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -notmatch "VPN"}).IPAddress

# Force SSH through physical interface
Start-Process "plink.exe" -ArgumentList "-bind $physicalInterface user@$sshServer"

Verify your SSH is using the correct interface:

C:\> netstat -ano | findstr "ESTABLISHED"
# Should show your physical interface IP as local address

For frequent users, create a dedicated network namespace:

# Requires admin rights
netsh interface ipv4 add route remote.server.ip/32 "Local Area Connection" physical.gateway.ip

Remember to test each solution in your environment, as network configurations vary.

When dealing with VPN connections on Windows, the system's routing table automatically prioritizes the VPN tunnel for all outbound traffic by default. This behavior causes SSH connections to fail when:

• The VPN enforces strict firewall rules blocking SSH
• The target SSH server only accepts connections from your original IP
• Network policy restricts VPN traffic to specific ports

While PuTTY doesn't have direct GUI options for interface binding, we can leverage Windows routing commands before establishing the connection:

# View current routing table
route print

# Add persistent route for SSH target (example)
route -p add 192.168.1.100 mask 255.255.255.255 192.168.0.1 if 15

Create a batch file that modifies routing temporarily during SSH sessions:

@echo off
:: Backup current route
route print > "%TEMP%\\route_backup.txt"

:: Add specific route for SSH server
route add 123.45.67.89 mask 255.255.255.255 192.168.0.1 metric 1

:: Launch PuTTY with your saved session
start "" "C:\\Program Files\\PuTTY\\putty.exe" -load "MySSHSession"

:: Wait for PuTTY to close
:loop
tasklist | find /i "putty.exe" > nul
if not errorlevel 1 (
    timeout /t 5 > nul
    goto loop
)

:: Restore original route
route delete 123.45.67.89

For more precise control over network interfaces:

# Get interface details
$interface = Get-NetAdapter | Where-Object {$_.Status -eq "Up" -and $_.InterfaceDescription -like "*Ethernet*"}

# Create temporary route
New-NetRoute -DestinationPrefix "123.45.67.89/32" -InterfaceIndex $interface.ifIndex -NextHop 192.168.0.1

# Execute PuTTY
Start-Process "putty.exe" -ArgumentList "-ssh user@123.45.67.89 -P 22"

# Cleanup when done
Register-ObjectEvent -InputObject (Start-Process putty.exe -PassThru) -EventName Exited -Action {
    Remove-NetRoute -DestinationPrefix "123.45.67.89/32" -Confirm:$false
}

Consider these SSH clients with native interface selection:

• MobaXterm: Has explicit "Network Adapter" dropdown in connection settings
• Bitvise SSH Client: Supports binding to specific interfaces under "Client" tab
• OpenSSH for Windows: Can use netsh interface ipv4 set interface commands

Verify your routing works before attempting SSH:

tracert -d 123.45.67.89
pathping 123.45.67.89