Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense + unRAID BitTorrent + AirVPN = Confusing

    OpenVPN
    2
    19
    2.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      monden2
      last edited by

      I ran a 'canyouseeme.org' check on the port, first two lines should represent the inbound traffic. Website posted back 'succes'

      TorrentStates2.jpg_thumb
      TorrentStates2.jpg

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • M
          monden2
          last edited by

          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.

          Screenshot_20180513-235840.png
          Screenshot_20180513-235840.png_thumb
          20180513_235300.jpg
          20180513_235300.jpg_thumb
          Screenshot_20180513-235108.jpg
          Screenshot_20180513-235108.jpg_thumb

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • M
              monden2
              last edited by

              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.

              OutboundNAT.JPG
              OutboundNAT.JPG_thumb

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • M
                  monden2
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • M
                      monden2
                      last edited by

                      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

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        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

                        1 Reply Last reply Reply Quote 0
                        • M
                          monden2
                          last edited by

                          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 )

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            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

                            1 Reply Last reply Reply Quote 0
                            • M
                              monden2
                              last edited by

                              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!

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.