Can't get port forward to work correctly.

viragomann

@undertaker666 said in Can't get port forward to work correctly.:

I could post the rules if that would help.

Yes, may help.

Port forwarding is quite simple.
If it isn't working also ensure that the target device is accepting the connections from WAN.

Is there a router in front of your pfSense?

Do you get the public IP on pfSense WAN? No CGN?

undertaker666

@viragomann
here are my Nat rules, both for parsec and bittorrent.

Here they are as they appear in the firewall WAN rules.

There is technically a router modem in front of my pfSense box, but it's in bridge mode, and I get a public IP and not one of the private networks in my WAN interface.

viragomann

@undertaker666
The firewall rules show that there ware already a few bytes passed by them.
That let me suspect that the NAT rules are working properly, but the destination devices may block the access.
So I guess, there's nothing wrong on pfSense.

However, if you want to further investigate on pfSense you can sniff the traffic on the internal interface with Diagnostic > Packet Capture and set the proper port filter, while you try to access from outside.
You should at least see incoming packets from the public IP, and also responses if the target device is responding.
If you see nothing check the WAN traffic.

undertaker666

@viragomann Those packets are rare, that's usually 0/0.
I check the “is my port open” website, and it showed up as open.

The BitTorrent client can download fine, and that traffic is not counted towards that NAT rule, however it will almost never upload.

I've seen suggestions to create an outbound NAT rule and try a lot of different things, but none of them worked.

I will also mention in case I forgot, I have Squid running MITM SSL Cache, Snort, and pfBlockerNG. But I don't see massive blocked traffic in the latter two.

crucialguy

@undertaker666 If an external port scan is seeing the port as open, then the NAT/Port Forward is operating ok, like viragomann said this points to a host problem.

With Torrent applications they can sometimes 'randomise' the port on startup, that's not happening here is it? Are you sure the application is set to use the same port every time it starts up?

I've never had to do anything more than you've done in order to get these sorts of scenarios working, just need to make sure the client it's self isn't trying to do UPnP or randomising the port on startup.

undertaker666

@crucialguy the problem is not with the host, the host was uploading fine before I switched to pfSense.

It is set to a specific port, otherwise I would not have set it to the number in the rule.

Again, you may be missing the point here, traffic in works fine, I can download at somewhat reasonable speeds, but there are no uploads happening at all.

undertaker666

@undertaker666 I forgot to mention, I also tried a few different torrent clients, all failed.

viragomann

@undertaker666 said in Can't get port forward to work correctly.:

the problem is not with the host, the host was uploading fine before I switched to pfSense.

Maybe your former router did masquerading on incoming forwarded packets.

Again, to get a step further sniff the traffic and show what you get.

undertaker666

@viragomann said in Can't get port forward to work correctly.:

Maybe your former router did masquerading on incoming forwarded packets.
Again, to get a step further sniff the traffic and show what you get.

Actually I didn't even have a port forward on my previous router, I had UPnP enabled on my client and everything worked.

Since moving to pfSense I disabled that, so that's not the cause.

As for sniffing, I'll try what you suggested and update this post.

undertaker666

@undertaker666

    92.14.118.168.34931 > 192.168.55.100.59372: [udp sum ok] UDP, length 1425
18:52:09.786523 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 44038, offset 0, flags [none], proto UDP (17), length 48)
    192.168.55.100.59372 > 92.14.118.168.34931: [udp sum ok] UDP, length 20
18:52:09.787142 , ethertype IPv4 (0x0800), length 590: (tos 0x48, ttl 53, id 45721, offset 0, flags [none], proto UDP (17), length 576)
    181.214.206.157.46682 > 192.168.55.100.59372: [udp sum ok] UDP, length 548
18:52:09.787395  ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 32769, offset 0, flags [none], proto UDP (17), length 56)
    192.168.55.100.59372 > 181.214.206.157.46682: [udp sum ok] UDP, length 28
18:52:09.788122  ethertype IPv4 (0x0800), length 590: (tos 0x48, ttl 53, id 45722, offset 0, flags [none], proto UDP (17), length 576)
    181.214.206.157.46682 > 192.168.55.100.59372: [udp sum ok] UDP, length 548

Here's a capture of the traffic coming in to that machine on that port. TCP is non-existent, it's all UDP for some reason. Even though the client is set to use TCP and UTP (which is UDP).
Other than that, I don't see anything else out of this capture.

viragomann

@undertaker666
So the traffic seems to flow well. That's all pfSense can do.

Actually I didn't even have a port forward on my previous router, I had UPnP enabled on my client and everything worked.

Would be worth to mention. Maybe UPnP opens more than only one port.

I'm using a BitTorrent client behind pfSense. I've forwarded two ports, one is TCP for talking to other client, the other UDP for the tracker, and it works flawlessly.

However, it's also possible to enable UPnP on pfsense, but that's only recommended if you know what you do and restrict the access to known clients only.

undertaker666

@viragomann Yeah UPnP is not secure, and it's better to stick to just 1 port.

I use QBittorrent, and there's only one port that can be set, so both use the same port, but only UDP is used for some reason.

undertaker666

@undertaker666 OK, did a bit more digging, and found out that pfBlockerNG was ignoring the rule order, and was still blocking the traffic that matched that NAT Rule.

Turned it off, but still not seeding well, so did a port test from both pfSense and outside the network using an online service.

External service said the port was closed, pfSense said the port was closed when the destination was the WAN IP, but when it was the LAN IP it said it was open.

Now why would that be?

lolipoplo

@undertaker666

easiest way to debug, run tcpdump on pflog0, you are going to see all of the blocked packets and according to which rule they are blocked, if they are indeed blocked.

tcpdump -nettti pflog0 port 8010 and then run an external syn scan on 8010

viragomann

@undertaker666 said in Can't get port forward to work correctly.:

Turned it off, but still not seeding well

Maybe QBittorrent needs the outbound port to be static.
Many consumer routers does this, but pfSense use random outbound ports by default. You may have to add an outbound NAT rule to achieve this.

pfSense said the port was closed when the destination was the WAN IP, but when it was the LAN IP it said it was open.

You cannot use the port check on pfSense for the firewall itself. You can only check other destinations.

lolipoplo

@viragomann if you have port forwarding working, outbound NAT doesn't matter. Making it static just helps with hole punching

viragomann

@lolipoplo said in Can't get port forward to work correctly.:

if you have port forwarding working, outbound NAT doesn't matter.

Some programs need this like several games. Maybe QBittorrent as well. I don't know how it works, as I mentioned above.
But it's for sure that QBittorrent also make upstream connections and these have nothing to do with forwarding at all.

So a presume, you're knowing well QBittorrent and can possibly give more reliable infos.

undertaker666

@viragomann @lolipoplo said in Can't get port forward to work correctly.:

tcpdump -nettti pflog0 port 8010 and then run an external syn scan on 8010

Actually, once I turned off pfBlockerNG, parsec managed to connect to a host game. So those ports are fine.

The problem is with the torrent, it's better, it's actually seeding now, and it actually reached 300 KB/s, but it does not stay at those speeds, and there's more downtime than actual seeding.

Maybe QBittorrent as well

Well, I already had outbound set up, so that's not what's stopping it. The question is why is pfBlockerNG ignoring the rule order, and even with it turned off, why are connections not sticking as they used to?

lolipoplo

@undertaker666
So have you tried pflog as I suggested?

Actually run tcpdump on wan port at the same time to compare incoming and rule matching

undertaker666

@lolipoplo No, because you suggested running the tcpdump on the parsec port, and that is solved by just turning off pfBlockerNG.

I could run the tcpdump on the qbittorrent port and see what happens.