Port Forwarding from VPN Provider to Torrent Client
-
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.
-
I clicked "Manual Outbound NAT rule generation" for "Firewall: NAT: Outbound" and accepted the defaults.
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)?
iii) What tools besides the built port checker in utorrent (i get inconsistent results with this) can I use to check if I am able to port forward?
I seem to have problems with uploading. The torrents I seed occassional get to about 30Kb then quickly die out.
-
-
Friendly bump…
-
I don't understand why you would need to port forward anything at a client if you are VPNed to a server. The server should be doing the port forwarding to handle incoming torrent connections, not the VPN client. As far as I know, once a client VPNs into a server all its ports are, effectively, open to all traffic from the server unless you have firewalled it somehow.
Maybe I'm just misunderstanding, but I think all the port forward action to accommodate the torrents, or anything for that matter, needs to happen on the server.
I would think, having not tried it, that getting a torrent or gnutella or something like that to work via VPN would be as simple as opening a port on the VPN server and VPNing in. I will say this. I can see where this would be alot easier if the VPN bridged to the same interface as say, the LAN and grabbed a predictable static IP there. The port forward from the vpn server will have to point to the exact IP of the VPN client, so you can't assign client IP's dynamically I would think.
-
To be brutally honest, I'm not sure I understand it either.
I all I know is that pfsense, via the interface PIANL, connects to the PIA vpn server. At which point I get a virtual ip and remote ip, and through the script I described above, I am returned a port.
At the very least, shouldn't I port forward that port to my internal torrent ip? More so, I really not sure what other NAT rules I need to make this work.
-
I'm thinking that the distant server should be the one doing the forwarding.
So you connect remotely via a VPN and lets say your computer gets assigned an IP of 10.5.18.12…
I think the distant end should open a port, lets say 43564 and that should be forwarded to 10.5.18.12:43564
And on your end, the client end seems to me you would just need to have that port open and have your P2P client listening on 43564
But this assumes alot - like, for instance, that your server is doing what it should.
I'm absolutely certain that I could do this no problems for myself using a VPN and a static port that doesn't change ever and just for me, but I'm pretty sure it would be difficult for me to write a script to make both ends set themselves up automagically on a variety of randomly chosen ports for a number of clients who come and go.
-
I guess a user had a similar issue http://forum.pfsense.org/index.php/topic=59158.0
User jimp suggested to do the following:
Interfaces > (assign), assign the OpenVPN interface (ovpncX) as a new OPT
Interfaces > OPTx (whatever you just made)
Enable, set IP type to 'none', save.
VPN > OpenVPN, edit/save the VPN once to make sure it's reinitialized (needed just this one time right after interface assignment)Then just add a port forward as you would on any other WAN.
I added the port forward as per below, with "add association rule" on.
What I don't understand, what happens to outbound traffic coming from 192.168.1.93 (the utorrent client VM)? Shouldn't it go out via the interface PIANL as well?
Again, what's more difficult for me to grasp is how to go about verifying this is actually working. The built-it port checker in utorrent says port is not open. But if I go to http://www.yougetsignal.com/tools/open-ports/ and input the remote ip for the tunnel (as in 109.201.., not the virtual one) and the port in question, it reports it as being open.
I am at a loss here.
-
Maybe your problem is that there are TCP vs UDP issue.
I've personally watched a guy go nuts thinking he had a port open only to find that he had opened TCP but needed UDP and that port checker was telling him the port was open but UDP was actually closed.
Do you need UDP? Is it open? I see directly above this only TCP is addressed, but further up this thread your rules reference both UDP and TCP.
So, maybe open both UDP and TCP on everything and then figure out for sure which you need. Perhaps you need both.
-
I think that the confusion arise when we deal with tunnels/VPN providers, because we don't know exactly what is going on the "end" of the crypto-tunnel and, consequently, which firewall/NAT rules we've to setup.
3 problems/questions here:
-
viewing your routes, is all the WAN traffic redirected to the tunnel?
-
are you correctly receiving DNS routes from the VPN provider?
-
have you setup a firewall rule to stop all the traffic when VPN provider disconnects?
Question #3 is important, because I was going crazy when my VPN provider disconnected for short amounts of time and the client/P2P was asking-going to another route…
-
-
Thanks for your reply panz,
For 1), as I understand it, and I could be wrong I have a rule that redirects all traffic from 192.168.1.93 to the PIANL (the vpn tunnel). Is this what you mean? So when I log into 192.168.1.93 and get the ip via ipchicken, i get the vpn provider's ip (109.201.. ), see below
- Where PIANL_IPS is an alias for the the IP , 192.168.1.93 and PIANL_VPNV4 is the gateway for the vpn tunnel
-
I honestly don't know how to verify this
-
I have not setup a firewall rule to stop all traffic when the VPN provider disconnects? Do you have a sample rule for me to look at?
Another thing, I am assuming that I could test the port forward on the virtual ip by logging in the pfsense box via ssh (192.168.1.1) and doing the following:
i)
telnet 10.126.. 41000
Correct? I get no response from the above.
ii)
telnet 192.168.1.93 41000
Works.
EDIT: I also tried i) by logging into a remote server and running that command, nothing. So the natting is not happening. Not sure why.
-
Thanks for your reply panz,
For 1), as I understand it, and I could be wrong I have a rule that redirects all traffic from 192.168.1.93 to the PIANL (the vpn tunnel). Is this what you mean? So when I log into 192.168.1.93 and get the ip via ipchicken, i get the vpn provider's ip (109.201.. ), see below
- Where PIANL_IPS is an alias for the the IP , 192.168.1.93 and PIANL_VPNV4 is the gateway for the vpn tunnel
-
I honestly don't know how to verify this
-
I have not setup a firewall rule to stop all traffic when the VPN provider disconnects? Do you have a sample rule for me to look at?
Another thing, I am assuming that I could test the port forward on the virtual ip by logging in the pfsense box via ssh (192.168.1.1) and doing the following:
i)
telnet 10.126.. 41000
Correct? I get no response from the above.
ii)
telnet 192.168.1.93 41000
Works.
EDIT: I also tried i) by logging into a remote server and running that command, nothing. So the natting is not happening. Not sure why.
-
Diagnostics –> Routes (aka netstat -rn)
-
see cmb reply on this thread "You can actually block that traffic using a quick floating rule matching out on WAN" http://forum.pfsense.org/index.php/topic,58694.0.html
(to be honest, I didn't get the result because of my ignorance. Any idea is on this topic would be very appreciated ;) )
telnet issue: I think that telnet is disabled by VPN provider.
Firewall rule on LAN: I think that is not going to match (can't see the previous rule, 'cause it's blurred), because "first match wins" default policy (LAN can go everywhere) above that is going to be applied first.
-
Again, I just wanted to say thanks for help. I really want this to work…
As for 2), receiving DNS routes from the vpn provider, I'm not sure if this is wrong or not. But when I log into my torrent box (.93) and run dnsleaktest.com I get not the VPN's dns providers but my local ISP's. Is this wrong? If so, how can I get the dns routes from the VPN provider? However, traffic going out this box is indeed going out the VPN.
- Sorry about the blurred out line, just thought it wasn't relevant. It's just directing another (different) IP address via the second VPN connection. I know this works.
About the telnet thing, I thought if the vpn provider would block telnet traffic, it would be on the default telnet port. I'm using telnet just to verify if utorrent is indeed listening to connections on the specified port. How else would you determine if the port forwarding is actually working?
This post, which I sort of model my config against, uses telnet as well. http://forum.pfsense.org/index.php?topic=57527.0
Also, utorrent's built-in port checker says the port is not open.
**EDIT:**Just to test that port forwarding is working, I tried running netcat (listening mode) on a random port on .93 and then attempted to connect via the WAN with telnet, and it works. So that's fine. However, when I try telnetting to utorrent's port from the WAN, nothing! But telnetting from within my LAN to utorrent works. So what gives…I really don't understand why it's not working.
-
DNS leaking. To use DNS server from the VPN provider you need to read the VPN connection logs. There, You should find the response from this server message:
http://openvpn.net/index.php/open-source/documentation/howto.html#dhcp
"Pushing DHCP options to clients:
The OpenVPN server can push DHCP options such as DNS and WINS server addresses to clients (some caveats to be aware of). Windows clients can accept pushed DHCP options natively, while non-Windows clients can accept them by using a client-side up script which parses the foreign_option_n environmental variable list. See the man page or openvpn-users mailing list archive for non-Windows foreign_option_n documentation and script examples.
For example, suppose you would like connecting clients to use an internal DNS server at 10.66.0.4 or 10.66.0.5 and a WINS server at 10.66.0.8. Add this to the OpenVPN server configuration:
push "dhcp-option DNS 10.66.0.4"
push "dhcp-option DNS 10.66.0.5"
push "dhcp-option WINS 10.66.0.8"To test this feature on Windows, run the following from a command prompt window after the machine has connected to an OpenVPN server:
ipconfig /all
The entry for the TAP-Windows adapter should show the DHCP options which were pushed by the server."
I use a different trick:
Setup at least 2 OpenNIC DNS servers in:
System –> General Setup > DNS server
and leave the "Use gateway" for them set to "none".
Then set the DNS forwarder service (dnsmasq):
Services: DNS forwarder
Enable DNS forwarderThen set the DNS server discovered on method 1 as FIRST DNS server before the other's OpenNIC;
After that, I set DNS forwarder to query NOT in parrallel, but in the order of preference listed in System –> General Setup > DNS server.
Read also:
https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142
Telnet thing: I suppose this is the theory behind that problem:
-
Have you gotten anywhere with this joelones? I have a very similar problem, using airvpn which has a fixed port forwarding so I don't have to struggle with scripts to get my port.
Outgoing traffic works fine, incoming traffic also seems to work fine in the log, but every test I've done from the outside indicates that the port forward doesn't work. By running tcpdump on the torrent machine itself, it seems to me like the torrent client also replies to the incomming packets, but that's the last time I find any trace of those packets. The firewall log doesn't show replies for an estabilished connection from what I understand, and any attempt I've made with packet capture on pfSense have led me nowhere. I haven't found any way to look at packets inside the tunnell either.
I've been doing most of this on 2.0.3, but since I read on this forum about the missing "reply-to" in 2.0, I've upgraded to 2.1 RC1 thinking that would solve the problem. The situation is still unchanged however, and I really don't know what do to from here. I log almost every rule there is (atleast every rule that has the slightest chance of being relevant) including "default block" rules, and I'm not seeing any drops in the log that has anything to do with this traffic. It simply seems to me like the reply packets vanish into a black hole.
panz: I don't really see how DNS leak would be relevant to get the port forwarding working.
-
Do you have routing problems?
Please post your routing table.
DNS (leak): using provider's DNS, as far as I know, could track your activity. So, your provider knows you're doing P2P. So, they can filter your traffic…
-
There might be some kind of a routing problem yes, but it's not in the vanilla routing table. My default gateway points to my WAN, and I use policy routing (that is: firewall rules with specified gateway) to route some of the traffic out the VPN tunnel. This policy routing doesn't apply to "missing traffic", since as far as I can understand the reply traffic for the port forwarded incoming traffic is seen as part of the incoming traffic. Hence it should be routed out the way it came in, but I'm not so sure it actually does and I can't find a way to be completely sure.
It would be nice if someone with more in-depth knowledge of the routing mechanisms in pfSense would shed some light as to how this is supposed to be handles, I'm assuming that the state table would play a role but it's not clear to me if the state table contains the "route back" information or how that is handeled. Knowing how it's supposed to work would hopefully make it easier to debug/check/verify.
Regarding the DNS leak issue I'm aware that my ISP could track my activity if I used my ISP's DNS, which I don't. I run my own DNS servers, and even in cases where I don't have internal DNS servers accesible I usually use openDNS servers. Since DNS traffic is unencrypted however, it would still be pretty easy for my ISP to read this traffic, but to be honest I'm not that paranoid. Anyhow, you're wrong about the filtering: They could filter the VPN tunnel itself, but they can't filter traffic inside the VPN tunnel. The VPN tunnel is up and working, so filtering is not an issue, and as said before, I really don't see how any DNS or ISP issue could interfere with only the port forwarded traffic inside a VPN tunnel.
-
I'm assuming that the state table would play a role but it's not clear to me if the state table contains the "route back" information or how that is handeled
All rules are stateful by default. When the traffic matches an "allow" rule, a table entry is created and, subsequently, all reply traffic is allowed (if that reply matches the entry).
-
When the traffic matches an "allow" rule, a table entry is created and, subsequently, all reply traffic is allowed (if that reply matches the entry).
Yes, that part isn't unclear to me - but rather where or how the information about the return route is stored. If the return route isn't stored, and reply packets simply follows the routing table then this can't work for policy routed VPN.
-
where or how the information about the return route is stored. If the return route isn't stored, and reply packets simply follows the routing table then this can't work for policy routed VPN.
Return route isn't stored; the table stores the reply that's expected (and firewall allows all the connections and any related traffic needed for the reply).
-
The return route has to be handles in some way; if it's not then port forwarding can never work for anything but the default gateway as I understand it. The reason for this, is that anything but the default gateway needs policy routing. Policy routing is achieved by using firewall rules, but the fact that a given packet matches the state table (a reply packet to an incoming port forwarded packet) means that it won't trigger the firewall rules and thus the policy routing won't come into effect. The packet will follow the normal routing table and exit via the default gateway.
It would be very interesting if someone with a good knowledge of pfSense could confirm how this really works.
EDIT: I just tested this by setting my default gateway to the VPN tunnel, and the port forwarding now works (even though it screws up a lot of other things on my network). This indicates that this is the problem, the question now is: Is there anyway in pfSense, pf or FreeBSD to create a policy routing that works also for the return packets even though they are in the state table already?
-
Have you gotten anywhere with this joelones? I have a very similar problem, using airvpn which has a fixed port forwarding so I don't have to struggle with scripts to get my port.
Outgoing traffic works fine, incoming traffic also seems to work fine in the log, but every test I've done from the outside indicates that the port forward doesn't work. By running tcpdump on the torrent machine itself, it seems to me like the torrent client also replies to the incomming packets, but that's the last time I find any trace of those packets. The firewall log doesn't show replies for an estabilished connection from what I understand, and any attempt I've made with packet capture on pfSense have led me nowhere. I haven't found any way to look at packets inside the tunnell either.
I've been doing most of this on 2.0.3, but since I read on this forum about the missing "reply-to" in 2.0, I've upgraded to 2.1 RC1 thinking that would solve the problem. The situation is still unchanged however, and I really don't know what do to from here. I log almost every rule there is (atleast every rule that has the slightest chance of being relevant) including "default block" rules, and I'm not seeing any drops in the log that has anything to do with this traffic. It simply seems to me like the reply packets vanish into a black hole.
panz: I don't really see how DNS leak would be relevant to get the port forwarding working.
Hi Nadar,
I'm not quite sure how to test this reliably (port forwarding to my internal ip). I tried running netcat (listening mode) on a random port on my internal utorrent box and then attempted to connect via the WAN with telnet, and it works. So that's fine. But to test the the incoming utorrent port has not worked. I noticed you used tcpdump to test this, can you elaborate on the steps involved in testing?
I also have another problem. I have two vpn connections but I would like a script which runs on the pfsense box to go out on through a specific vpn, but it goes out through the wrong one. I'm not sure how to alter this behaviour in pfsense. I used policy routing as well.
In System->Routing->Gateway, the default gateway is the WAN. So at the very least I would expect traffic from the pfsense (192.168.1.1) box to out via the WAN.I also changed System->Routing->Routes and added:
where PIANL is the interface I would like .1 traffic to go out from. It was working, for awhile at least…
