PfSense + unRAID BitTorrent + AirVPN = Confusing
-
Those rules look correct. If adding a port to the deluge container allowed it to respond to a TCP test it must be working.
Check the state table for incoming states to the internal IP.
It seems likely something internal just isn't responding/listening for some reason.
Steve
-
Here is the state table for the internal IP.
I blacked out the VPN IP, and the external IP is the IP address belonging to the tracker where the announcements are sent (for which it appears no traffic is going through).
-
That state is outbound traffic from the internal host and there's no reply to it. The tracker is not replying or replying incorrectly.
There isn't any inbound traffic shown. Try generating some test traffic to the VPN IP and see if it creates states.
Steve
-
That is a bit the issue. Because the torrent annoucement isn't going out, it cannot get a list of download peers to initiate a download. Hence, I cannot initiate traffic specifically for this route.
I know the VPN's work, because I have normal internet which is routed through it. This is also verified by my VPN provider.
Also, NZBD downloads are working fine as well. It's only the torrent downloads that aren't initiating. -
Ok, I can't say why the tracker is not responding. From the states there it looks like it's not sending a single packet back. That's nothing to do with the port forwards though, that's all outbound traffic.
However you can test the inbound traffic by generating any TCP connection from an external host to your VPN IP on the right port. It will create a state if the port forwards are working even if the internal machine refuses the connection.
Steve
-
I ran a 'canyouseeme.org' check on the port, first two lines should represent the inbound traffic. Website posted back 'succes'
-
Ok, well that's a different WAN. If both those addresses you have labelled as 'VPN IP' are the same then one of them is wrong. And since the connection succeeds on VPN3 it looks like the IP for VPN1 is wrong. That would explain why the outbound connection there is failing also. Can we see your outbound NAT settings page?
P.S. your screenshots are HUGE! ;)
Steve
-
Yeah, I just figured taking print screens on a 4k monitor makes big Screenshots, even when I trim out all the bits. So let's try on my phone.
I don't think the IP is an issue. All 3 connections have their own IP address assigned, and I have a VPN group to balance the load between the 3 of them. In this case the latency of VPN1 was the lowest, hence it picked that one for the screenshot of the state table. I've seen the same issue with the other VPN connections. And like I mentioned, my non-torrent clients and regular Internet work fine on all 3 connections. I've attached a screenshot to show all 3 connections are active and sending/receiving traffic.
I also attached the routing table and the NAT table.
-
Those are actually even bigger, but with less information in them! ;)
Anyway can we see the outbound NAT rules screen. That's where it looks like the issue is from what we see on the state table. Unless the 'VPN IP' label was for two different IPs?
If it was then something else is preventing the tracker replying.
Those gateway monitoring values look bad. No way they should be showing 0ms.
Steve
-
Yes, the VPN IP for the inbound traffic was a different IP than the outgoing one, as inbound was on VPN3 (ends with .143) and outbound was on VPN1 (ends with .14).
But i added the outbound NAT table anyway :)
The torrent client sit on the 192.168.1.* subnet. I also have a 192.168.10.* subnet for my remote OpenVPN connections when I am outside my network.
-
Mmm, yeah that looks good. Hard to say why the outbound connection is not working then.
Does other outbound traffic work from the torrent client machine?
Steve
-
I think so. It is an unraid server, with multiple packages ("containers") on it (the torrent client being one of them). Each container has an own IP address and Port to access/be accessed on the network. All containers work without any issues. Also my VM's on the server have an Internet connection.
Even when I remote connect my phone/laptop via OpenVPN, it gets it's 192.168.10.* subnet IP, which is then going out over my secured VPN
-
Then I'd have to guess an issue with the tracker setup. Looks like the port forwards and VPN is all configured correctly at this point.
Steve
-
That was my initial though as well, but I do not know if the tracker setup is something in pfSense (e.g. I forgot to put some rule in or check a certain box, which is why udp tracker traffic is being blocked), or whether it is due to my torrent client not being correctly configured. :o
-
The problem appears to be with the initial http connection from the client to the tracker. Nothing is coming back. Almost like it's using the wrong IP address. Or maybe your public IP is blocked by the tracker.
What error do you see at the client?
Does it work if you configure it to not use the VPN?
This doesn't appear to be an issue with the pfSense setup from what we can see.
Steve
-
From the torrent client side it goes from 'Tracker: Announcement Sent' to 'Tracker: Error - Timeout'. This happens regardless of which tracker I use (I added 10 downloads in the meantime, all of them the same failure). If it goes directly over my non-VPN WAN, I have no issues.
Also, in the past I used to have a download client from AirVPN which opened the VPN tunnel for me (similar to OpenVPN client software). This would also ussually not cause an issue.
Finally, the container was also available in a 'VPN Configuration', where the container directly connects to the VPN network. Again, no issues there (if we can't find a way to solve it, I might just revert the torrent client to a VPN config directly over WAN :P )
-
Ok well I think you;re going to need to confirm the torrent client has any outbound connectivity somehow then.
If you can't run a test from it directly the get a packet capture filtered by it's internal IP on LAN to make sure at least something is coming back to it.
Steve
-
So, I have no idea why it worked, but I installed the VPN version of the client, and it started downloading! I guess the container might be a bit buggy? It's double tunnelled now, so the client makes a VPN connection to the VPN network by using the original VPN tunnels.
This stuff makes my head spin!
