Leaderboard

Hello! p2p is allowed on pool 2 but it can be really used only by those programs that let you configure which IP address to announce (non existing, as far as we know). More in general, pool 2 is not suitable for any program which announces itself autonomously. In AirVPN infrastructure, the VPN traffic reaches the Internet through one exit IP address, but "pool 2" is the set of ports of another IP address (let's name it exit IP address 2, in brief exit 2). If a program receives an unsolicited incoming packet from the Internet through exit 2, it will reply properly. This happens whenever you advertise on your own how to reach your service (a web or FTP server, a game server, and so on). However, with p2p programs, it's the program itself which must advertise. DHT or a tracker will record the address they receive the advertisement (of the port etc.) from, and they will say to other peers that your p2p program is reachable on exit 1, with its pool 1 ports; however, if you have remotely forwarded a pool 2 port, peers would never be able to reach your program, because they would send packets to a port of another IP address (exit 1, the address recorded by DHT and/or trackers). The problem could be resolved by manual setting (see for example https://userpages.umbc.edu/~hamilton/btclientconfig.html#BTConfig ) when you need to seed only - additional tests are required. This is an important limitation that might be overcome in the future, for example by letting the user pick which exit IP address its traffic must go to the Internet through. In the meantime, by using pool 2 (and when necessary additional pools) for anything different from p2p and crypto wallets, port exhaustion problem is solved (in most cases only 1 forwarded port is needed for p2p). Kind regards

Here’s how I solved it: 1. Setup VPN Interface with Policy-Based Routing: • First, I set up WireGuard as the VPN client on my Unifi gateway. Many VPN providers allow you to download a WireGuard config that can be uploaded into Unifi. • Once the VPN is configured, you can create a Policy-Based Route to specify which devices or networks should use the VPN for outbound traffic. This step ensures your internal devices route traffic through the VPN tunnel. 2. Solution: Custom Firewall and NAT Rules: To make port forwarding work, I had to set up both a custom firewall rule and a Destination NAT rule. Step-by-Step Setup: • Firewall Rule: 1. Go to Firewall & Security → Create a new rule under “Internet In”. 2. Action: Set to “Accept”. 3. Protocol: Select TCP/UDP (or any specific protocol you need). 4. Source: Set to Any. Since the traffic is coming from the internet via your VPN, it’s important to allow any source. 5. Destination: This should be the internal IP of the device you want to forward traffic to (e.g., 192.168.1.xxx). 6. Destination Port: Set the specific port you’re forwarding. 7. Save the rule. • NAT Rule (Destination NAT): 1. Go to Network Settings and create a Destination NAT rule. 2. Set the Interface to your WireGuard VPN interface. 3. Destination Address: Set this to the internal IP address from the VPN tunnel (the IP assigned to you by your VPN provider within the VPN network, e.g., 10.x.x.x). 4. Translated IP Address: Set this to the local IP of the device in your network (e.g., 192.168.1.xxx). 5. Ports: Match the Destination Port to the port you are forwarding.