a7b4f5b3 0 Posted ... I've created a VPN on VPS with port forwarding so I'm familiar with setting up these rules, but the ports I get don't seem to work. I am trying to forward Transmission on a port (lets just say 12345 as an example so I don't list my actual port). I already have a working pfSense OpenVPN connection via UDP 443 Entry3. I can confirm the client I want this VPN for gets that IP and there is no DNS leak. I set port 29379 in Transmission and disabled the "Use port forwarding from my router". In addition, I have UPnP/NAT-PMP disabled. I did not alter the local port when I requested the port, so local and remote are both 12345. It shows the correct exit IP and tunnel IP. I setup the port forward on my pfSense 2.4.4 router as follows:Interface: AIRVPNProtocol: TCP/UDPDestination: AIRVPN addressDestination Port Range: Other 12345 to Other 12345Redirect Target IP: 192.168.2.12Redirect Target Port: 12345 This creates an associated NAT rule as well. I did not need to edit it.Interface: AIRVPNProtocol: TCP/UDPDestination: 192.168.2.12Destination Port Range: Other 12345 to Other 12345 This rule configuration is all I needed to make my homemade OpenVPN server forward ports. For example, I could use port 12345 and redirect to SSH on a LAN client. I would simply replace the destination port range with 12345 and redirect target port with 22, and I'd set that VPN as the interface/gateway instead of AIRVPN, and everything works from there. Quote Share this post Link to post
tehhellhound 8 Posted ... I will be interested in hearing the solution to this because I use Tomato firmware but I am having the exact same problem for a while and it actually used to work. I know that the actual port forward is working, which you should actually test yourself in your case, because I have my Android TV box establish a separate VPN connection using OpenVPN client for Android so that I can easily exclude things like Netflix. I can forward ports to that box just fine. Only problem is forwarding through the router. I know iptables pretty well so chances are if they find a solution for you I can adapt it. Quote Share this post Link to post
Staff 9973 Posted ... Hello!The key here is that you need to forward packets from the tun interface to the final IP address of the machine running the service. Here's a guide on how to do it via iptables:https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Kind regards Quote Share this post Link to post
a7b4f5b3 0 Posted ... Hello!The key here is that you need to forward packets from the tun interface to the final IP address of the machine running the service. Here's a guide on how to do it via iptables:https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Kind regards I am using pfSense, which doesn't use iptables. However, I have a different OpenVPN server not associated with AirVPN where I created rules to handle port forwarding. I wrote equivalent rules that should work in AirVPN's case, but they don't. I used to use ASUS Merlin to where I used similar iptables rules, then I had to translate them to pfSense's way for the other VPN. But it's the same concept. My VPN forwards the port to the tunnel IP (this is handled on your end when the port forward lists the private IP).Then the router listens on that IP, forwards it to the destination IP. I have those rules working for several ports through a different service, but I got AirVPN because that VPN doesn't allow P2P. The same rules should work because they do the same as the iptables. Quote Share this post Link to post
Staff 9973 Posted ... I am using pfSense, which doesn't use iptables. Hello! iptables is available for *BSD but you don't really need it, just use pf instead. I have those rules working for several ports through a different service, but I got AirVPN because that VPN doesn't allow P2P. The same rules should work because they do the same as the iptables. We went ahead and since your account was connected to some server we tested directly from inside that server. We can confirm that remote port forwarding works perfectly and packets were forwarded to your node properly, on the correct port. Kind regards Quote Share this post Link to post
a7b4f5b3 0 Posted ... I am using pfSense, which doesn't use iptables. Hello! iptables is available for *BSD but you don't really need it, just use pf instead. >>I have those rules working for several ports through a different service, but I got AirVPN because that VPN doesn't allow P2P. The same rules should work because they do the same as the iptables. We went ahead and since your account was connected to some server we tested directly from inside that server. We can confirm that remote port forwarding works perfectly and packets were forwarded to your node properly, on the correct port. Kind regards It's definitely not forwarding. At this point I know my rules can't be wrong. I took my custom VPN, forwarded the same port I opened on AirVPN, and redirected it to SSH on a VM. Attempting to SSH on that port on my self made VPN server correctly SSHs into that VM. I do not use a different local port in my config, the redirection is done on the router's firewall rule. I then change the interface from my custom VPN to AirVPN and it doesn't work. Also, I can run a port checker site on that port. It shows my custom VPN public IP as open, but doing so on AirVPN's exit IP as closed. The configuration I'm using should work on any VPN service that allows for port forwarding. Quote Share this post Link to post
Staff 9973 Posted ... It's definitely not forwarding. At this point I know my rules can't be wrong. It's definitely working properly on our side. We even checked explicitly on your VPN IP address while you were connected. Something is wrong in your configuration, and it's not necessarily the prerouting or forward rules. Feel free to open a ticket. See here:# iptables-save | grep 10.19.50.97-A PREROUTING -d 213.1x2.1xx.5/32 -p tcp -m tcp --dport 2x379 -j DNAT --to-destination 10.19.50.97:2x379-A PREROUTING -d 213.1x2.1xx.5/32 -p udp -m udp --dport 2x379 -j DNAT --to-destination 10.19.50.97:2x379 That's directly from inside the server you are connected to (some octet digits and the forwarded port have been edited for your privacy, while 10.19.50.97 is your IP address in the VPN). As you can see everything is fine. Kind regards Quote Share this post Link to post
a7b4f5b3 0 Posted ... It's definitely not forwarding. At this point I know my rules can't be wrong. It's definitely working properly on our side. We even checked explicitly on your VPN IP address while you were connected. Something is wrong in your configuration, and it's not necessarily the prerouting or forward rules. Feel free to open a ticket. See here:# iptables-save | grep 10.19.50.97-A PREROUTING -d 213.1x2.1xx.5/32 -p tcp -m tcp --dport 2x379 -j DNAT --to-destination 10.19.50.97:2x379-A PREROUTING -d 213.1x2.1xx.5/32 -p udp -m udp --dport 2x379 -j DNAT --to-destination 10.19.50.97:2x379 That's directly from inside the server you are connected to (some octet digits and the forwarded port have been edited for your privacy, while 10.19.50.97 is your IP address in the VPN). As you can see everything is fine. Kind regards I'll open a ticket, but those rules are exactly how I do forwarding on a self-built VPN server, so logically it should also work the same on the client side. Quote Share this post Link to post