Leaderboard

If I understand you, then this is what I do on remote Linux servers, when I want to run a VPN client on them: https://github.com/tool-maker/VPN_just_for_torrents/wiki/Maintaining-SSH-Access-Using-a-VPN-on-a-Remote-Linux-Server It allows me to connect to SSH through the real network interface, rather than having to go through a forwarded port on the VPN server.

Hello! This is expected. More details on why it can't work later on this message. Expected too, due to the routing table and also the Network Lock if enabled. If you need traffic leaks so that a listening program is reachable both on the "real" public IP address and on the VPN server exit-IP public address, you should disable Network Lock (or re-configure it accordingly), have a program listen to all interfaces, define (only when necessary) source based routing, and configure WireGuard NOT to route all traffic inside the tunnel (**). This means that you tried to reach the listening program on the VPN interface IP address from inside the same LAN, or to the public VPN server IP address (or through the DDNS, same thing) - this is an error because then the physical reply is necessarily routed into the VPN tunnel (check your system's routing table (*) and you will immediately see why; or that WireGuard is tunneling the whole IP space (default behavior with Eddie Desktop edition). As you noted: You must contact the service directly on the LAN and you have to make sure that WireGuard does not send everything inside the VPN tunnel (**), to avoid that the reply is routed in the VPN tunnel and becomes un-routable on the VPN server. The interpretation you give here is not totally correct. It's true that the physical reply is routed finally through eth (just like anything else, because a virtual network sooner or later must rely on something physically existing), but the packets transiting there have been already encrypted and wrapped. The final destination address is the original sender address through the VPN routing. The reply (the underlying payload of the traffic) then gets lost as expected because it must go to the same public IP address of your router, i.e. the same public IP address the VPN server sees your client connecting from, which is also the same public IP address the request to your listening service comes from, in the eyes of the VPN server. This is very strange. Maybe you had a different setup in Windows? Anyway the correct behavior is the one you just described on Linux. (*) Please note that if you have enabled multiple routing tables then source based routing may become strictly necessary to ensure that responses to packets received from an interface are always sent back from the same interface. From your description this doesn't seem the case, but if it is, please keep it into consideration. You will also need that devices in the same LAN can route outgoing traffic to different public IP addresses to contact a listening service (through the VPN) of a machine in the same LAN. It doesn't make sense anyway, just pass through the LAN. (**) The option to do so is currently not implemented in Eddie Desktop edition, but only in Eddie Android edition. It is planned anyway on an imminent AirVPN Suite for Linux release. Please see here for a thorough explanation and a possible solution: https://airvpn.org/forums/topic/55801-wireguard-access-local-network/?do=findComment&comment=217458 Kind regards

Hello! @dhch The more extended tests on Mint 21.3 allowed to detect the problem. When ufw is running, it sets a series of custom rules. If you then enable network lock with Bluetit in default configuration, Bluetit stores the rules through nft (correctly). However, the system translation from ufw/iptables rules to nft syntax goes horribly wrong. When Bluetit restores the previous firewall status, the restore fails because during the previous translations syntax errors were introduced in the file where the previous rules were saved. This is a well known / notorious issue since years ago, it's the translation problem we wrote about in our previous message. After that, Bluetit even crashes (core dump you may have seen), so it will also fail to restore DNS system settings if a connection was performed during the session. This crash must be investigated of course: it is triggered by nft critical error (it exits with unknown error 256), so we should be able to avoid the crash, but the syntax errors caused by the system commands during the translations are unavoidable, they are system tools intrinsic. It is not in our scope to fix what's lost in translation; the problem can be avoided in other ways. By not running ufw when you start Bluetit, you will also be able to avoid another problem we see in your log. The solution is the one we recommended before: make sure that ufw is disabled when you start Bluetit, or force Bluetit's network lock to fall back to iptables. To disable ufw: sudo ufw disable Please let us know whether any problem still persists after you test Bluetit with ufw disabled. Kind regards

Hello @Staff, I noticed that all of the 10G duplex servers are based in Europe and Americas. Is there any plans to add 10G servers to Asia?

I just wanted to request a server in Denmark

Yes, a Danish server would be most appreciated!