Port Forwarding from VPN Provider to Torrent Client
-
I have a similar issue as this user: http://forum.pfsense.org/index.php/topic,59158.0.html
So to recap my VPN provider (Private Internet Access), allows you to forward one (and only one) port through the VPN tunnel back to your computer. This single forwarded port is usually used for the listening port for torrent transfers, it ensures that you're connectable.
I've created a script (on the pfsense VM) which is able to get the forwarded port (which PIA assigns) and I am able to update that port on my torrent client which resides on another VM on a private IP. The Openvpn connection is established on the pfsense.
I'm just not sure just what needs to be done on the pfsense VM to forward that port to the internal torrent client.
The previous thread seem to point towards this snippet of code: http://forum.pfsense.org/index.php/topic,60341.0.html
My question, with the "pfctl -f" command is it possible to update a Port Foward with a new port and if so, have is that accomplished with the "-f" switch?
I am using 2.1RC1.Please, thoughts?
-
So I'm really not sure about this, but this is what I did. I would really appreciate someone to look over this. TIA.
This is the scenario:
-
pfsense establishes a vpn connection with PIA and I've created an interface for it called PIANL. I receive a remote and virtual IP address 109.201.. / 10.126..
-
I also have a script that gets a port from a server which lies through the interface PIANL, (the script resides on pfsense, local ip: 192.168.1.1) and updates a torrent client's (utorrent client: 192.168.1.93) port used for incoming connections. This all works.
What I don't understand is how to ensure that pfsense doesn't block incoming connections …
This is what I did:
- In Firewall->Rules->LAN(Tab), I created the following rule:
Where the alias PIANL_IPS contains the IP 192.168.1.93. So, this should direct all traffic from the ip address 192.168.1.93 through the vpn connection.
- In Firewall->Rules->PIANL(Tab), I created these rules. Probably redundant or incomplete. Dunno?
I'm assuming the first rule allows all traffic on the PIANL to a "PIANL address". Is the "PIANL address" the remote (109.201..) or virtual (10.126.. ) one?
The second rule there probably doesn't make sense, allow all traffic on the PIANL interface to the local IP 192.168.1.93???
- Lastly, here's where it gets even more complicated for me. In this case I know the port to be forwarded, let's say 41000. so I added this to Firewall->NAT->Port Foward (Tab)
Which should port forward the port in question to the internal IP (192.168.1.93).
TWO THINGS:
i) Does this make sense?
ii) If i) is true, how can I automate the script on the pfsense box to update the port in 3)?
I seem to have problems with uploading. The torrents I seed occassional get to about 30Kb then quickly die out.
-
-
This is how it works (My example is on the BitCoin Wallet, however it also works the same way with BT and any other software requiring open ports.)
You just need those 2 Rules
The Firewall rule to allow the incoming connection from the VPN to your Network:
(You might be able to be more "secure" when saying "Destination => LAN Subnet" but I never tested it)NAT does the forward to the specific client/server in your network.:
Just make sure your VPN ISP really does support port forwarding on the Server you have selected ! I had some issues with this in the beginning and realized real late that port forwarding was not enabled on the VPN Server I have chosen
-
I have a small issue with the port forwarding from VPN too. Everything works correctly (have the port forwarded from the OpenVPN interface to my local station) If I use the routes added automatically with the OpenVPN connection, the port forwarding is great, but it adds a few routes including 0.0.0.0/1 that go out the vpn interface which takes over my default gateway. When I add route-nopull and just copy all the routes that it adds except for 0.0.0.0/1, the VPN works fine except the port doesn't forward anymore. If I had that route, it starts working again.
It's very possible I just don't know how to properly add the route to make this work. I'm attaching a screenshot that shows the route 0.0.0.0/1 using 10.30.0.5 over the ovpnc1 interface. When that is removed, the VPN still works fine with my rules in place, just the port forward stops. The port is being forwarded to a PC on my OPT network. Any suggestions are appreciated!
-
We're discussing the exact same issue in this thread: http://forum.pfsense.org/index.php?topic=65230.new;topicseen#new
From what I can understand, the reason is that the reply-to address for some reason isn't used for the return packets for the associated firewall rule for the port forwarding NAT rule. I've managed to get it to work by:
On the NAT port forwarding rule, select "none" under "Filter rule association". Create the rule manually instead, under floating rules. The rule is basicly a "copy" of the one automaticly created by NAT:
Pass, Quick, in, IPv4, <protocol>, source: any, Destination: port forwarding destination host, Destination port range: forwarded port
Make sure it's high up/on top in the floating rules, and make sure it's a quick rule. When I look in rules.debug, the effect of this is simply that the rule (it's the firewall rule that contains the reply-to address) ends up much higher in the resulting ruleset, and that seems to make all the difference. I haven't quite figured out why yet.</protocol>
-
We're discussing the exact same issue in this thread: http://forum.pfsense.org/index.php?topic=65230.new;topicseen#new
From what I can understand, the reason is that the reply-to address for some reason isn't used for the return packets for the associated firewall rule for the port forwarding NAT rule. I've managed to get it to work by:
On the NAT port forwarding rule, select "none" under "Filter rule association". Create the rule manually instead, under floating rules. The rule is basicly a "copy" of the one automaticly created by NAT:
Pass, Quick, in, IPv4, <protocol>, source: any, Destination: port forwarding destination host, Destination port range: forwarded port
Make sure it's high up/on top in the floating rules, and make sure it's a quick rule. When I look in rules.debug, the effect of this is simply that the rule (it's the firewall rule that contains the reply-to address) ends up much higher in the resulting ruleset, and that seems to make all the difference. I haven't quite figured out why yet.</protocol>
I tried this out, but the port still doesn't work unless I add the 0.0.0.0/1 route in. Ah well, I can deal with it for now.
-
We're discussing the exact same issue in this thread: http://forum.pfsense.org/index.php?topic=65230.new;topicseen#new
From what I can understand, the reason is that the reply-to address for some reason isn't used for the return packets for the associated firewall rule for the port forwarding NAT rule. I've managed to get it to work by:
On the NAT port forwarding rule, select "none" under "Filter rule association". Create the rule manually instead, under floating rules. The rule is basicly a "copy" of the one automaticly created by NAT:
Pass, Quick, in, IPv4, <protocol>, source: any, Destination: port forwarding destination host, Destination port range: forwarded port
Make sure it's high up/on top in the floating rules, and make sure it's a quick rule. When I look in rules.debug, the effect of this is simply that the rule (it's the firewall rule that contains the reply-to address) ends up much higher in the resulting ruleset, and that seems to make all the difference. I haven't quite figured out why yet.</protocol>
You sir are a genius. This worked for me and it's been something that I'd long since given up trying to get working.
-
On the NAT port forwarding rule, select "none" under "Filter rule association". Create the rule manually instead, under floating rules. The rule is basicly a "copy" of the one automaticly created by NAT:
Pass, Quick, in, IPv4, <protocol>, source: any, Destination: port forwarding destination host, Destination port range: forwarded port</protocol>
I had to resurrect the old thread to say thanks. I had the exact same issue, and the floating quick rule did the trick. Thanks.
-
We're discussing the exact same issue in this thread: http://forum.pfsense.org/index.php?topic=65230.new;topicseen#new
From what I can understand, the reason is that the reply-to address for some reason isn't used for the return packets for the associated firewall rule for the port forwarding NAT rule. I've managed to get it to work by:
On the NAT port forwarding rule, select "none" under "Filter rule association". Create the rule manually instead, under floating rules. The rule is basicly a "copy" of the one automaticly created by NAT:
Pass, Quick, in, IPv4, <protocol>, source: any, Destination: port forwarding destination host, Destination port range: forwarded port
Make sure it's high up/on top in the floating rules, and make sure it's a quick rule. When I look in rules.debug, the effect of this is simply that the rule (it's the firewall rule that contains the reply-to address) ends up much higher in the resulting ruleset, and that seems to make all the difference. I haven't quite figured out why yet.</protocol>
Thanks! You saved me from a lot of troubleshooting. Is this a bug which has still not been fixed?