I've requested a forwarded port, lets just say the port is gb-lon- 33333, I've gone to Tixati's settings and under Network > Incoming Ports and in "TCP/TDP port for peer connections and messages" I've put "33333" (The same as the port given by Mullvad). I've then gone into Network > Connections and under "Local IPv4 Address or interface" I've selected Mullvad Tunnel. However I am still "Downloading 0 (0) 0 (0)"
This all looks good to me. Exactly as you should do, it had to work at this point! But to calm you down: it's not a problem with Tixati.
Some troubleshooting tips and sanity checks:
1) While disconnected, port-forward on the website and wait a few minutes before connecting to the server and trying. Afaik you need to connect to that specific server with Mullvad to receive port-forwarding
2) Have you tried an actually active torrent?
Try any popular Linux distribution:
Scroll down for torrents:
https://ubuntu.com/download/alternative-downloads
WARNING: This page is very heavy. debian-10.9.0-amd64-DVD-1.iso has 550 seeders currently, you can find a magnet-link elsewhere too.
http://bttracker.debian.org:6969/stat
3) Firewall? Oh the Windows Firewall... Ideally you should've been asked whether to allow Tixati. You'll have to check for it manually in Windows Firewalls advanced settings. By default Windows blocks all incoming connections, that's exactly what we want here though!
3.1) Enable the WF log file. It's a continuously updated log file, you'll have to reopen it every once in a while or use notepad++ with 'View -> Monitoring (tail -f)' mode
4) Port checker tools. If you search online you will only find port check websites. They're all TCP (alright with us) but they all require a running application behind the port. I.e. Tixati must be running for the port check to be correct.
I can't find any without ads, (this one contains Google tracking): portchecker (dot) co. It works correctly if the app behind the open port is running.
5) DIY port checker. This allows for more control and easier troubleshooting later on.
You need 2 machines, a smartphone with Termux would do. Alternatively you need to manually 'bind' or 'specify source IP' for tools on your machine such that one tool listens on VPN connection (like Tixati) and another queries it using your regular home connection.
Tools to be used:
Client (connecting to ...): telnet, nc (aka BSD netcat), port checker websites. All of these are TCP, idk about UDP off the top of my head.
Server (listening for incoming connections): obviously Tixati, SuperSimpleServer, ... iperf or even the Minecraft server lol, both two will show you in console who tried connecting - that's all we need
I will show examples below based on nc and iperf. nc is a basic network communication tool, iperf is a speedtest tool, but works fine for us and its tiny too. If you are on Windows you can use WSL or Cygwin to install those (or maybe find binaries online), if you are on Linux you need no further explanation because you are a smart cookie.
Example, testing connection with nc:
nc -zv -w 2 104.244.42.65 80 - try TCP/80 connection to a twitter server, 2s timeout.
Success:
Connection to 104.244.42.65 80 port [tcp/http] succeeded!
Fail:
nc: connect to 104.244.42.65 port 8080 (tcp) timed out: Operation now in progress (if in doubt, increase timeout)
Tell nc to use a different source IP address:
nc -zv -w 2 -s 192.168.1.42 104.244.42.65 80 - instead of '192.168.1.42' choose your LAN IP address and it will use your normal LAN connection. On Windows you can see all IPs with
ipconfig /all, on Linux
ip a. Of course you can look them up in Tixati settings too.
Setting up iperf:
Example connecting:
iperf --port 3321 --client 127.0.0.1 - connect to port 3321 on local machine. CTRL+C to abort.
success:
[ 3] local 127.0.0.1 port 42503 connected with 127.0.0.1 port 3321 - and it begins a speedtest attempt against the app behind that port, so exit quickly. This run in particular was pointed at Tixati, you could use iperf alone to test for open ports theoretically :)
failure:
connect failed: Connection refused
Example iperf server (listening on port):
iperf --server --bind 127.0.0.1 --port 12345 - listen on port 12345 ONLY on the internal 127.0.0.1 interface. Default (aka 0.0.0.0) is all available interfaces.
Example success output:
iperf --server --bind 127.0.0.1 --port 12345
------------------------------------------------------------
Server listening on TCP port 12345
Binding to local address 127.0.0.1
Just don't kill it by closing console or with CTRL+C or it will stop listening :)
Example failure:
iperf --server --bind 126.0.0.1 --port 12345
bind failed: Cannot assign requested address
------------------------------------------------------------
Server listening on TCP port 12345
Binding to local address 126.0.0.1
This will be enough for you to start troubleshooting on your own in a controlled manner. Don't forget to restart these simple applications if you disconnect/reconnect the VPN. Tixati is smart enough to retry later when VPN becomes available, these aren't (iperf keeps running even though it failed to bind as shown above, not sure if it would work later on in this state)
For a start, launch iperf on 127.0.0.1 and connect to it with nc to verify you are doing everything right.
iperf --server --bind 127.0.0.0 --port 12345
# in a second console window:
# here you obviously connect to yourself, from addr 127.0.0.1 to addr 127.0.0.1:12345
nc -zv -w 2 -s 127.0.0.1 127.0.0.1 12345
After this continue with the VPN testing.
iperf --server --bind <internal VPN IP as shown by OpenVPN> --port <local port or aka port-forwarded port>
# in a second console window:
nc -zv -w 2 -s <your LAN IP> <external VPN IP, hopefully shown by websites> <port-forwarded port>
I hope I didn't make a mistake above. That's how you test connectivity of your VPN port-forwarded application without needing anything else. The application (here: iperf or Tixati) will use the VPN conn, and nc will test using your regular connection.
-------------
6) Heavy artillery: Wireshark. That's your last resort to see if any packets arrive at all. You will need to get accustomed to filtering there, but that's the only thing you need to find packets you are interested in. Plenty tutorials online.
If you see no packets incoming there're still two reasons left: the firewall somewhere very deep inside is dropping them OR the port-forwarding doesn't actually work (or you try to ping the wrong external IP)
I'm done. 6.5k symbols. DONATE TO TIXATI DEV!
