What is TCP:S and how do I unblock it?
-
I tried to set up bittorrent tonight, I have opened the incoming port by creating a rule for all TCP traffic on port 3333 to be allowed inbound to the box running the BT client.
The inbound traffic is still being blocked, and the log entries look like this:
Jun 21 19:58:21 WAN 64.171.133.152:62929 192.168.1.2:3333 TCP:S
Jun 21 19:58:13 WAN 79.9.109.52:2155 192.168.1.2:3333 TCP:S
Jun 21 19:58:10 WAN 91.207.184.46:4060 192.168.1.2:3333 TCP:SSo incoming traffic from the WAN, from WAN IPs, on any port, destination 192.168.1.2 port 3333 (ALL of this matches exactly the rule permitting the incoming traffic) is still being blocked.
It is showing up as TCP:S - I presume this is because the torrent clients encrypt their data to try to defeat ISPs doing traffic shaping, and TCP:S means secure or similar.
I presume that is why my rule is not working, but I have tried other options (TCP/UDP which I thought might cover all the "normal" protocols) in the
"protocol" setting in the rule and cannot find anything that works. It is no good to me setting it to "any" protocol since that would basically mean opening all ports inbound to that host (you can't choose which ports if you do "any" protocol, since of course stuff like ICMP doesn't use ports).What's the solution - how do I allow this TCP:S traffic inbound on a particular port or ports?
-
In "TCP:S", the S is the TCP flag. It's a "syn" flag, which means it is trying to establish a connection. There is a link at the bottom of the firewall logs page which explains what the flags mean.
Most likely, you do not have the correct firewall rule in place to allow that traffic. You need both a NAT Port Forward entry and a firewall rule.
Alternately, you could enable UPNP on your pfSense router and in your BT client, I know it works with utorrent, and probably would with anything that properly supports UPNP.
-
Thanks for the reply,
The NAT port forwarding is being done by another box which directly connects to the internet, pfsense is then behind the DMZ and just needs the correct port opening, so all traffic on port 3333 received from the WAN by the other firewall is port forwarded to 192.168.1.2 port 3333, this traffic is routed via pfsense (which does no NATing) to the host. The packets arrive with intact WAN addresses and
The two boxes are also the reason that uPNP isn't ideal, and I also don't like running anything that lets clients open ports, I'd rather do it explicitly on the firewall myself.
Thanks again for the help, knowing the S is just a flag to say it's a syn is useful but still doesn't entirely answer my question - does anyone know why my rule permitting all TCP connections to 192.168.1.2 port 3333 is generating blocks in the logs as shown in my original post?
-
Ok, thanks to the pointer that TCP:S is a syn packet I have fixed this by changing the source from "wan address" to "any". This is not ideal but good enough for me, however it does raise the question of what "wan address" means - does it mean only something on the same subnet as the routers WAN interface? Ie. if the WAN is 192.168.240.0 then 192.168.240.123 would be a "wan address" whilst 123.134.122.222 would not be? Seems slightly odd behaviour, surely "wan address" would normally mean anything not on the LAN???
Thanks.
-
When dealing with port forwards, the destination IP is always the "internal" IP address, never a WAN address. The rule still goes on the WAN tab though. And with traffic coming from the internet, you never need to set a "source" address, that is not rewritten anywhere, and will always be the original IP.
As I mentioned in the previous message, you did not have the correct firewall rule in place to allow that traffic, which is why it was being blocked.
