NAT not working as expected.
-
Hello,
I have been playing with pfSense on my home network for about a month now and have been very happy with it. It is currently running as a virtual machine under ESXi and I couldn't be more pleased with the performance. In an attempt to create a more secure network I have created a DMZ and am running a torrent server in it for all of my various linux iso's and the like. However, it isn't performing as expected and I would like some input.
By default, with no port forwarding configured I expect that no traffic would be passed to the dmz at all, meaning that no torrents would be able to download or upload, but this doesn't seem to be the case. Upnp is turned off and I plan to forward only ports 6881-6889 to the DMZ. I noticed some strange behavior when I checked the firewall logs on my torrent server (ubuntu running UFW) and saw that it had blocked connections from external IP addresses with various source and destination ports (non of which were 6881-6889). My impression was that no traffic should have been passed to the torrent server at all on those ports. This happens even with all port forwarding and firewall rules regarding the DMZ turned off. Further, with all NAT and Firewall rules turned off I am still able to download and upload torrents normally. Can anyone offer some insight as to why this is the case?
The following settings are with port forwarding to the DMZ turned off along with the associated rules. This still permits traffic to the DMZ and normal torrent function.
Thanks.
-
What guide did you follow to setup the dmz?
Your rule there on DMZ that allows all traffic to everything but lan net would allow internet access, you can for sure download torrents without a port forward, etc.
-
I used the following docs to set up the DMZ.
http://doc.pfsense.org/index.php/PfSense_2_on_VMware_ESXi_5
http://doc.m0n0.ch/handbook-single/#id2604946I was under the impression (perhaps mistakenly) that the rules applied to connections coming into the interface. So, while the rule on the DMZ interface would allow all traffic it would need to get through the WAN interface first before it got to the DMZ. Without Upnp or ports forwarded how would incoming connections get through? I can see outgoing connections being passed, but not incoming.
Thanks.
-
The incoming traffic you are seeing to the DMZ network through WAN is most likely return traffic for traffic originating from the DMZ network.
PFSense is a stateful firewall meaning it will allow return traffic which matches an existing state.
If you go to Diagnostics > States you should be able to see established connections from the DMZ network out to various peers on the Internet.
-
Okay, so at the moment I have port forwarding and Upnp turned off. So the reason torrents are working is because they are initiated from the DMZ and are passed through the WAN interface because they are return traffic? Would this be the case if I weren't using a stateful firewall (such as linux)?
Should I even bother turning port forwarding on if I can use the torrent server as expected? I'm trying to make the security as tight as possible (which requires full understanding) and would like as few holes in the firewall as possible. Currently there is only a hole for OpenVPN to pass through.
-
If you want to optimize p2p speeds, then you would want to allow for unsolicited traffic – a forward to whatever port your p2p client is using. You would not need to forward a range. Your client is only listening on 1 port not a range of ports.
But sure you can get downloads of torrents without allowing for unsolicited traffic.
Where did you get the idea that a linux firewall was not stateful?
"the rules applied to connections coming into the interface."
That is correct - inbound on the interface, from the dmz towards the router. Would be inbound - from the router to the dmz those rules would not apply.And as mentioned already you allow out from the dmz, so he goes to say pfsense.org - the return traffic from pfsense.org hits your wan interface, and there is a state there where you initiated the traffic, so the traffic is allowed through the wan and then out the dmz interface to your client.
What you would not allow for is unsolicited traffic to your dmz client without a forward. Ie pfsense.org could not talk to your dmz client unless your dmz client started the conversation In the case with p2p it does and can work both ways. When your client is asking for stuff you hit a member of the swarm and ask, hey do you have this - that peer sends it back to your dmz client - hits your routers wan and there is that state from your created traffic so the traffic gets back to your dmz client.
In other cases members of the swarm will see your peer and want to ask if you have piece X of the torrent, but since that traffic to you would be unsolicited your router would not send that traffic into your dmz client. Now that peer my might say hey screw that peer, if he asks me for something I am going to tell him to get bent. So depending on the size of the swarm, the amount of seeds compared to peers your speed might be crap if you do not allow for inbound traffic. You can always grab from a seed, he is not going to be asking you for stuff in return. But if your pulling mostly from peers and your not allowing them to ask you for stuff they are not going to like that ;) and might not send you stuff when you ask them.
-
I think I read through your initial post too quickly, I though you were running a torrent client in the DMZ rather than a torrent server/tracker, in which case I wouldn't expect to see traffic being initiated from the torrent server/tracker, at least not actual torrent traffic anyways.
Perhaps you can stop your torrent server application, clear all states involving the DMZ devices (From the Diagnostics > States page), start a packet capture on the WAN interface in pfSense, start the torrent server application again and let the packet capture run for a few minutes.
Once you have done that, check the states page again and check if you see any states involving devices in the DMZ (Or optionally check the firewall log for any dropped packets on the WAN interface destined for the DMZ network).
Once you stop the packet capture and open it in Wireshark, you should be able to see if the torrent server application initiated any outbound traffic to WAN, and identify which hosts it has initiated traffic with.
-
It seems I have misunderstood a couple of things. I was under the impression that IPtables wasn't stateful, but if it is I may have to give Ubuntu server a try as a firewall (thank you for the clarification). Also, I am running Ubuntu server in the DMZ with Rtorrent / Rutorrent, which I think is just a client. I'm still playing with this setup and I'm learning as I go.
-
To be honest I can not think of a nonstateful firewall, that would just an old school packet filter. Your talking the 80's for that sort of thing ;) Stateful took over in the early 90's if I recall.
-
Great, thank you for your replies. If I understand johnpoz post correctly then I will open ports 6881-6889 in the firewall and point them to the DMZ to allow people to query me for file pieces. The rules for the firewall and NAT are already in the images I posted, so I will just re-enable them. Are the rules I have in the images alright or should I modify them?
-
" I will open ports 6881-6889 in the firewall and point them to the DMZ "
Must of been something I was not clear about? I thought I clearly stated you only need 1 PORT, are you running 9 clients?? using those 9 different ports? Your client only listens on 1 port. And to be honest I would not pick those ports, those are really old school p2p ports. I for example use 42312. You can pick whatever port you want! Look on your client, what port are you set for - this is the port you need to forward.
-
I did change it to one port at your suggestion, but this was after I noticed you edited your initial post. I was using a range because I had initially looked into a turnkey torrent server but was unimpressed with it. The instructions for the turnkey was to forward a range. Is there any advantage to using a higher port number or is this just something to keep you off the ISP's radar?
-
What turnkey server? A range still don't make any sense to me, would love to read their docs - do they have multiple listeners for trackers or something?
Other than not falling into the old school p2p range, any port is just as good as any other – I would wouldn't pick a well known worm port or service port ;)
-
Thank you for your replies. I will continue to play with this setup but am quite happy with it. For reference, this is the turnkey server I was talking about: http://www.turnkeylinux.org/torrentserver
Thanks!
-
Thanks - yeah that looks to be using MLdonkey as a multi protocol sharing server, web/ftp, bittorrent, emule, etc. The turnkey docs/tutorial for that appliance are a bit lacking from just a 2 second look. And yeah they do say to forward that range - why I am not sure. Clearly from the mldonkey site, and even from their example on the turnkey site they show the portcheck script used 6882 so why would they say forward that range?
http://mldonkey.sourceforge.net/WhatFirewallPortsToOpen#Incoming_connections
BitTorrent client_port = 6882 bittorrent.ini