Port Forwarding from VPN Provider to Torrent Client
-
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… -
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'm running transmission on Debian - since you're referring to uTorrent, I'm guessing you're torrent machine is running Windows. WinDump is supposedly tcpdump's windows counterpart, but WinDump is a command line tool and I'd rather go for Wireshark on Windows. What I did was simply to watch traffic coming in to the correct IP and forwarded port, and then watch outgoing replies going back out to the same hosts shortly thereafter. That told me that the port fortwarding was working, and that the torrent client was replying. After that I couldn't figure out where the packets went, but if you read my later posts in this thread you can see that I think I found the cause of the problem: The return packets aren't affected by the policy routing and hence is going out the default gateway instead of the VPN connection.
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.That part I know little nothing about, it all depends on the functions in the script and whether you can bind those to specific interfaces. You might for example create a Virtual IP on the pfSense box which you bind your script functions to, and then policy route everything from that virual IP out the correct gateway.
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…I don't think you wanna do that, it's like creating a second default gateway and I don't know what the consequences of that will be. Rather, just as a test, go to the gateway tab and set the "port forwarding vpn interface" as the default gateway instead of your WAN just to test the port forwarding. In my case, that solves it, and the port forwarding works. It's not a solution however, because all kind of other traffic is supposed to go out the WAN interface and even if I used policy routing for this it would disable any port forwarding done on the WAN (like FTP etc). But, it's a nice test to estabilish where the problem is. The next question is then how to apply policy routing to packets that match the state table, that is packets that's being considered part of an incoming connection. I haven't figured out yet if pfSense has support for multiple routing tables, but that might be one possible solution - I'm simply not sure.
-
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.
At this point, I can't see the purpose of the firewall! :o
You've the box completely opened. ;D
-
I gave up trying to forward from the pfsense box, instead I installed openvpn client on the torrent box which makes the vpn connection and requests the port from the PIA server. I figured it would be easier this way.
Although, I think no port forwarding needs to be done at the level pfsense, but I'm wondering if I need anything else for this work, other nat / rules.
I was able to run tcpdump from the torrent client (on the tun0 device) and from the exterior I telnetted into the PIA IP and forwarded port (which in turn forwards the same port on the virtual ip address) and I did see traffic on the same port. So I am assuming this is working?
However my upload speeds are not moving, and Im still wondering if I'm missing something. Can someone confirm if the output from the tcpdump makes sense (not real IPs)
Forwarded Port: 24900
PIA VPN IP: 109.12.33.34
VIRTUAL IP: 10.123.5.7exterior:
telnet 109.12.33.34 24900tcpdump on torrent client:
23:24:20.392117 IP 96.123.244.15.34878 > 10.123.5.7.24900: Flags [s], seq 803332574, win 14600, options [mss 1368,sackOK,TS val 155770005 ecr 0,nop,wscale 7], length 0 23:24:20.392143 IP 10.123.5.7.24900 > 96.123.244.15.34878: Flags [S.], seq 170698842, ack 803332575, win 14480, options [mss 1460,sackOK,TS val 3013110 ecr 155770005,nop,wscale 7], length 0 23:24:20.604061 IP 96.123.244.15.34878 > 10.123.5.7.24900: Flags [.], ack 1, win 115, options [nop,nop,TS val 155770068 ecr 3013110], length 0 23:24:20.604167 IP 10.123.5.7.24900 > 96.123.244.15.34878: Flags [F.], seq 1, ack 1, win 114, options [nop,nop,TS val 3013163 ecr 155770068], length 0 23:24:20.814180 IP 96.123.244.15.34878 > 10.123.5.7.24900: Flags [F.], seq 1, ack 2, win 115, options [nop,nop,TS val 155770131 ecr 3013163], length 0 23:24:20.814203 IP 10.123.5.7.24900 > 96.123.244.15.34878: Flags [.], ack 2, win 114, options [nop,nop,TS val 3013216 ecr 155770131], length 0[/s] -
Bump^
