search

TunnlTo / desktop-app

TunnlTo is a Windows WireGuard VPN client built for split tunnelling.
https://tunnl.to
1.5k stars 62 forks source link

ISSUE: config #185

Closed macsunmood closed 5 months ago

macsunmood commented 5 months ago

Describe the issue If Allowed Apps field is specified, will also specifying Allowed IPs limit the IP use for the specified apps ? Doesn't seem to work for me now (for instance, I set "chrome" as specified app, but setting specific allowed IPs won't limit chrome to tunneling only them, and chrome would still use vpn for any ip). When using the WireGuard client without tunneling, everything works smoothly. However, when employing TunnelTo with specific IP settings for tunneling, the website fails to load, returning the following error: image Any ideas what can be done about this?

To Reproduce The rules:

IP Addresses: 104.18.35.28, 104.18.33.45, 104.18.37.228:443, 104.18.41.158, 104.18.33.170, 104.18.32.115, 172.64.146.98, 172.64.150.28, 172.64.154.211, 104.31.16.120, 104.31.16.9, 13.107.246.67, 23.102.140.112/28, 13.66.11.96/28, 104.210.133.240/28, 188.114.99.224, 34.128.128.0, 104.18.7.192

Expected behavior Should split tunnel all of the above IPs (in the rules) over VPN when using any app (chrome, etc.). Should successfully load chat.openai.com.

Tested on official WireGuard client Are you experiencing the same issue using the official Windows WireGuard client?

Tested on different VPN servers Are you experiencing the issue on multiple VPN servers?

Logs When Enabling the tunnel and trying to load a chat.openai.com webpage in Chrome:

2024-05-15 11:36:40 [TUN]: keep_alive_thread: Sending Keepalive packet to WireGuard Server success

2024-05-15 11:36:33 [TUN]: keep_alive_thread: Sending Keepalive packet to WireGuard Server success

2024-05-15 11:36:15 [TUN]: Handshake response received from ***:***

2024-05-15 11:36:15 Wireguard tunnel has been started.

2024-05-15 11:36:15 [MGR]: Tunnel has started

2024-05-15 11:36:15 [TUN]: Sent handshake packet to the WireGuard server at ***:***

2024-05-15 11:36:15 [TUN]: Using local IPv6 = *** for the {***}

2024-05-15 11:36:15 [TUN]: Using local IPv4 = *** for the {***}

2024-05-15 11:36:15 [TUN]: Detected default interface {***}

2024-05-15 11:36:15 [MGR]: Using WireGuard server: ***:***

2024-05-15 11:36:15 WireSock Service has started.

WireSock WireGuard VPN Client 1.2.37 is running as a regular process.

Starting WireSock directly The outcome is the same.

wiresock commented 5 months ago

Please be aware that the IP 104.18.37.228:443 in your AllowedIps list does not appear to be a valid IP or subnet address.

You may want to consider testing a non-public update available at the following links:

This update includes improvements in configuration parsing and introduces an additional parameter, Socks5ProxyAllTraffic. When set to true, this setting ensures that all WireGuard packets, not just the handshake, are routed through the SOCKS5 proxy.

macsunmood commented 5 months ago

Please be aware that the IP 104.18.37.228:443 in your AllowedIps list does not appear to be a valid IP or subnet address.

You may want to consider testing a non-public update available at the following links:

This update includes improvements in configuration parsing and introduces an additional parameter, Socks5ProxyAllTraffic. When set to true, this setting ensures that all WireGuard packets, not just the handshake, are routed through the SOCKS5 proxy.

Hi, thank you for suggestion, but this is how TunnlTo behaves after installing the new WireSock version: image

wiresock commented 5 months ago

Hmm, it worth limiting the check to Major and Minor versions only...

Anyways, can you run WireSock in console mode and check if the issue persists?

macsunmood commented 5 months ago

Please be aware that the IP 104.18.37.228:443 in your AllowedIps list does not appear to be a valid IP or subnet address.

You may want to consider testing a non-public update available at the following links:

This update includes improvements in configuration parsing and introduces an additional parameter, Socks5ProxyAllTraffic. When set to true, this setting ensures that all WireGuard packets, not just the handshake, are routed through the SOCKS5 proxy.

I've run the console mode WireSock: wiresock-client.exe run -config C:\Users\***\AppData\Local\TunnlTo\tunnel.conf -log-level all, then ran chrome and tried to open the website - failed. Here's the log:

2024-05-15 16:54:01 WireSock WireGuard VPN Client Service 1.2.41
The service is starting using C:\Users\***\AppData\Local\TunnlTo\tunnel.conf WireGuard client configuration.

WireSock WireGuard VPN Client 1.2.41 is running as a regular process.
2024-05-15 16:54:01 WireSock Service has started.
2024-05-15 16:54:01 [MGR]: Using WireGuard server: ***:***
2024-05-15 16:54:01 [TUN]: Detected default interface {***}
2024-05-15 16:54:01 [TUN]: Using local IPv4 = 192.168.199.5 for the {***}
2024-05-15 16:54:01 [TUN]: Using local IPv6 = *** for the {***}
2024-05-15 16:54:01 [TUN]: Sent handshake packet to the WireGuard server at ***:***

2024-05-15 16:54:01 [MGR]: Tunnel has started
2024-05-15 16:54:01 Wireguard tunnel has been started.
2024-05-15 16:54:01 [TUN]: Handshake response received from ***:***
2024-05-15 16:54:26 [TUN]: keep_alive_thread: Sending Keepalive packet to WireGuard Server success
wiresock commented 5 months ago

Could you please provide additional lines from the log? Also, could I take a look at your configuration, excluding any keys and endpoint addresses?

macsunmood commented 5 months ago

Could you please provide additional lines from the log? Also, could I take a look at your configuration, excluding any keys and endpoint addresses?

Thanks for pointing out, you're right , here's some additional lines:

2024-05-15 21:50:07 [FILTER]: C:\Program Files\Google\Chrome\Application\chrome.exe : TCP : 192.168.199.5:58957 -> 104.18.32.115:443
2024-05-15 21:50:07 [FILTER]: ekrn : TCP : 192.168.199.5:58959 -> 104.18.32.115:443
2024-05-15 21:50:17 [TUN]: wireguard_read result = 0 size = 0

Here's the tunnel.conf contents:

[Interface]
PrivateKey = ***
Address = 100.90.112.218

[Peer]
PublicKey = ***
PresharedKey = ***
Endpoint = ***:***
AllowedIPs = 104.18.35.28, 104.18.33.45, 104.18.37.228, 104.18.41.158, 104.18.33.170, 104.18.32.115, 
172.64.146.98, 172.64.150.28, 172.64.154.211, 104.31.16.120, 104.31.16.9, 13.107.246.67, 23.102.140.112/28, 13.66.11.96/28, 104.210.133.240/28, 188.114.99.224, 34.128.128.0, 104.18.7.192

The website now actually loads to just black screen. There're hints that not all the necessary data is possible to load: image

...but I have no clue what can be done, because I've already tried and added all possible IPs addresses...

brendanosborne commented 5 months ago

It looks like you're encountering a CORS issue due to a mismatch in how resources are being accessed between your VPN and your normal internet connection. Here’s a breakdown of the situation:

Accessing the Main Website

Loading Resources from CDNs

CORS Policy in Action

Resulting Issue

macsunmood commented 5 months ago

It looks like you're encountering a CORS issue due to a mismatch in how resources are being accessed between your VPN and your normal internet connection. Here’s a breakdown of the situation:

Accessing the Main Website

  • You access the ChatGPT website through a VPN server, which means the request to load the main website originates from the VPN server's IP address.

Loading Resources from CDNs

  • The JavaScript on the ChatGPT website attempts to load additional resources (e.g., scripts, stylesheets, images) from various CDNs.
  • These requests to the CDNs are made from your normal internet connection, not routed through the VPN. Hence, they originate from your personal IP address.

CORS Policy in Action

  • The CDNs have CORS policies in place that check the origin of requests. When a request is made to a CDN, the CDN server checks the Origin header to determine if the request is allowed.
  • Since your IP address (personal connection) is different from the VPN server's IP address, the CDN identifies this discrepancy. The CDN might not recognize the request’s origin as permitted because it expects the request to come from the same IP address that accessed the main website (the VPN server’s IP address).

Resulting Issue

  • The CDN rejects the requests made from your normal internet connection due to the CORS policy, causing the resources to fail to load. This leads to errors on the website since the necessary resources are not being retrieved.

Thank you for the detailed breakdown! That's exactly what I thought the actual problem is. But can anything be done about it ? I've already added the cdn.oaistatic.com IP address to the config, but it won't help...

wiresock commented 5 months ago

Why not dedicate a specific browser to ChatGPT and set AllowedIps to 0.0.0.0/0 and AllowedApps to your chosen browser?

brendanosborne commented 5 months ago

Those CDN's will probably have hundreds or more IP addresses and they could change at any time. Plus it might start breaking your other web browsing as other sites you visit through your normal connection will have the CDN routed through the VPN.

I would install a seperate browser and send all of its network activity through the VPN as wiresock suggested. Just consider that your VPN browser.

Alternatively, have a look into CORS proxies https://httptoolkit.com/blog/cors-proxies/

macsunmood commented 5 months ago

@wiresock , @brendanosborne , thank you very much! I'm gonna try both ways - separate browser and proxies.