How to Get Port 12010 Working Again

This topic has been deleted. Merely users with topic management privileges can see information technology.

@undertaker666
The firewall rules show that there ware already a few bytes passed by them.
That permit me suspect that the NAT rules are working properly, only the destination devices may block the access.
So I judge, in that location's zip wrong on pfSense.

Notwithstanding, if you desire to further investigate on pfSense y'all can sniff the traffic on the internal interface with Diagnostic > Package Capture and set the proper port filter, while y'all endeavor to admission from outside.
You should at to the lowest degree encounter incoming packets from the public IP, and also responses if the target device is responding.
If you see nothing check the WAN traffic.

@viragomann Those packets are rare, that's usually 0/0.
I bank check the "is my port open" website, and information technology showed up as open.

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

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

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

@undertaker666 If an external port browse 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 tin sometimes 'randomise' the port on startup, that's not happening here is it? Are you sure the application is prepare to use the same port every time it starts upward?

I've never had to do annihilation 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 exercise UPnP or randomising the port on startup.

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

It is prepare to a specific port, otherwise I would not accept set it to the number in the dominion.

Again, y'all may be missing the bespeak hither, traffic in works fine, I can download at somewhat reasonable speeds, but there are no uploads happening at all.

@undertaker666 I forgot to mention, I as well tried a few dissimilar torrent clients, all failed.

@undertaker666 said in Tin't become port forward to work correctly.:

the trouble is non with the host, the host was uploading fine earlier I switched to pfSense.

Maybe your former router did masquerading on incoming forwarded packets.

Once again, to go a footstep further sniff the traffic and show what you go.

@viragomann said in Can't get port forrard 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 fifty-fifty take a port forrard 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 endeavor what you lot suggested and update this post.

@undertaker666

                              92.xiv.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, commencement 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, outset 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, outset 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'due south a capture of the traffic coming in to that machine on that port. TCP is non-existent, it'due south all UDP for some reason. Even though the client is set up to use TCP and UTP (which is UDP).
Other than that, I don't run across annihilation else out of this capture.

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

Really I didn't even take a port frontward 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'chiliad using a BitTorrent client backside pfSense. I've forwarded ii ports, 1 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 simply recommended if you know what y'all exercise and restrict the access to known clients only.

@viragomann Yep UPnP is not secure, and information technology'due south better to stick to only one port.

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

@undertaker666 OK, did a fleck more digging, and establish out that pfBlockerNG was ignoring the rule club, and was still blocking the traffic that matched that NAT Rule.

Turned it off, but still non seeding well, so did a port exam 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, merely when it was the LAN IP it said it was open.

Now why would that be?

@undertaker666

easiest fashion to debug, run tcpdump on pflog0, you are going to see all of the blocked packets and co-ordinate to which dominion they are blocked, if they are indeed blocked.

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

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

Turned it off, simply all the same not seeding well

Maybe QBittorrent needs the outbound port to be static.
Many consumer routers does this, merely pfSense use random outbound ports past default. You may take 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 up.

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

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

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

if yous accept port forwarding working, outbound NAT doesn't affair.

Some programs demand this like several games. Possibly QBittorrent also. I don't know how information technology works, equally I mentioned in a higher place.
But it'southward for certain that QBittorrent also brand upstream connections and these have nothing to do with forwarding at all.

Then a assume, y'all're knowing well QBittorrent and can possibly requite more than reliable infos.

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

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

Actually, in one case 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 at present, and it actually reached 300 KB/s, but it does not stay at those speeds, and in that location's more downtime than bodily seeding.

Maybe QBittorrent besides

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

@undertaker666
And then have y'all tried pflog as I suggested?

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

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

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

@undertaker666

              tcpdump -nettti pppoe0 port 59372 -vv tcpdump: listening on pppoe0, link-blazon Zip (BSD loopback), capture size 262144 bytes  00:00:00.000000 AF IPv4 (2), length 56: (tos 0x2,ECT(0), ttl 63, id 28582, offset 0, flags [none], proto TCP (6), length 52)     My-WAN.31533 > 172.sixteen.1.0.59372: Flags [Sew together], cksum 0xbecc (correct), seq 2428356104, win 62720, options [mss 8960,nop,wscale eight,nop,nop,sackOK], length 0  00:00:00.013465 AF IPv4 (2), length 48: (tos 0x2,ECT(0), ttl 254, id 6409, offset 0, flags [DF], proto TCP (6), length 44)     172.xvi.one.0.59372 > My-WAN.31533: Flags [S.], cksum 0x9772 (correct), seq 4044710442, ack 2428356105, win 4200, options [mss 1400], length 0  00:00:00.000241 AF IPv4 (2), length 44: (tos 0x0, ttl 63, id 28583, offset 0, flags [none], proto TCP (vi), length 40)     My-WAN.31533 > 172.16.one.0.59372: Flags [.], cksum 0xc3ca (correct), seq ane, ack 1, win 64400, length 0  00:00:00.003992 AF IPv4 (2), length 205: (tos 0x0, ttl 63, id 28584, offset 0, flags [none], proto TCP (6), length 201)     My-WAN.31533 > 172.16.1.0.59372: Flags [P.], cksum 0xc832 (right), seq 1:162, ack 1, win 64400, length 161  00:00:00.302961 AF IPv4 (two), length 205: (tos 0x0, ttl 63, id 28585, outset 0, flags [none], proto TCP (vi), length 201)     My-WAN.31533 > 172.16.one.0.59372: Flags [P.], cksum 0xc832 (correct), seq i:162, ack one, win 64400, length 161  00:00:00.394904 AF IPv4 (2), length 205: (tos 0x0, ttl 63, id 28586, offset 0, flags [none], proto TCP (6), length 201)     My-WAN.31533 > 172.sixteen.one.0.59372: Flags [P.], cksum 0xc832 (right), seq 1:162, ack 1, win 64400, length 161  00:00:00.699004 AF IPv4 (2), length 205: (tos 0x0, ttl 63, id 28587, offset 0, flags [none], proto TCP (half-dozen), length 201)     My-WAN.31533 > 172.16.one.0.59372: Flags [P.], cksum 0xc832 (right), seq 1:162, ack 1, win 64400, length 161  00:00:00.589524 AF IPv4 (2), length 56: (tos 0x2,ECT(0), ttl 63, id 36468, offset 0, flags [none], proto TCP (vi), length 52)     My-WAN.60033 > 172.xvi.2.0.59372: Flags [SEW], cksum 0x442d (correct), seq 3544223184, win 62720, options [mss 8960,nop,wscale viii,nop,nop,sackOK], length 0  00:00:00.013934 AF IPv4 (2), length 48: (tos 0x2,ECT(0), ttl 254, id 9436, offset 0, flags [DF], proto TCP (6), length 44)     172.16.two.0.59372 > My-WAN.60033: Flags [S.], cksum 0x3e54 (correct), seq 3004006065, ack 3544223185, win 4200, options [mss 1400], length 0  00:00:00.000178 AF IPv4 (two), length 44: (tos 0x0, ttl 63, id 36469, beginning 0, flags [none], proto TCP (vi), length 40)     My-WAN.60033 > 172.16.2.0.59372: Flags [.], cksum 0x6aac (correct), seq 1, ack one, win 64400, length 0  00:00:00.005371 AF IPv4 (two), length 497: (tos 0x0, ttl 63, id 36470, offset 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.sixteen.2.0.59372: Flags [P.], cksum 0x62af (correct), seq 1:454, ack 1, win 64400, length 453  00:00:00.385924 AF IPv4 (2), length 497: (tos 0x0, ttl 63, id 36471, offset 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.xvi.2.0.59372: Flags [P.], cksum 0x62af (correct), seq 1:454, ack 1, win 64400, length 453  00:00:00.304076 AF IPv4 (two), length 205: (tos 0x0, ttl 63, id 28593, offset 0, flags [none], proto TCP (vi), length 201)     My-WAN.31533 > 172.sixteen.ane.0.59372: Flags [P.], cksum 0xc832 (correct), seq ane:162, ack 1, win 64400, length 161  00:00:00.095936 AF IPv4 (two), length 497: (tos 0x0, ttl 63, id 36472, get-go 0, flags [none], proto TCP (half dozen), length 493)     My-WAN.60033 > 172.16.ii.0.59372: Flags [P.], cksum 0x62af (correct), seq i:454, ack 1, win 64400, length 453  00:00:00.218016 AF IPv4 (2), length 44: (tos 0x0, ttl 254, id 10875, offset 0, flags [DF], proto TCP (half dozen), length 40)     172.16.1.0.59372 > My-WAN.31533: Flags [R.], cksum 0xbf57 (correct), seq 1, ack i, win 0, length 0  00:00:00.476972 AF IPv4 (2), length 497: (tos 0x0, ttl 63, id 36477, offset 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.16.2.0.59372: Flags [P.], cksum 0x62af (right), seq 1:454, ack 1, win 64400, length 453  00:00:01.204971 AF IPv4 (2), length 497: (tos 0x0, ttl 63, id 36480, showtime 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.16.ii.0.59372: Flags [P.], cksum 0x62af (right), seq 1:454, ack 1, win 64400, length 453  00:00:00.323059 AF IPv4 (2), length 44: (tos 0x0, ttl 254, id 13669, kickoff 0, flags [DF], proto TCP (6), length 40)     172.16.2.0.59372 > My-WAN.60033: Flags [R.], cksum 0x6639 (correct), seq 1, ack i, win 0, length 0                          

Here's a small output of that command.

The weird thing is, when I do canyouseeme, it shows me another public IP than what is shown in the WAN interface on my pfSense box.
Both are public IPs, and I tested both, and now they say closed.

@undertaker666

if you lot aren't willing to practise tcpdump on pflog0 you can't see how your packets get blocked

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

@undertaker666

                tcpdump -nettti pppoe0 port 59372 -vv tcpdump: listening on pppoe0, link-type NULL (BSD loopback), capture size 262144 bytes  00:00:00.000000 AF IPv4 (two), length 56: (tos 0x2,ECT(0), ttl 63, id 28582, offset 0, flags [none], proto TCP (6), length 52)     My-WAN.31533 > 172.16.1.0.59372: Flags [Stitch], cksum 0xbecc (right), seq 2428356104, win 62720, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0  00:00:00.013465 AF IPv4 (ii), length 48: (tos 0x2,ECT(0), ttl 254, id 6409, offset 0, flags [DF], proto TCP (half-dozen), length 44)     172.16.1.0.59372 > My-WAN.31533: Flags [South.], cksum 0x9772 (correct), seq 4044710442, ack 2428356105, win 4200, options [mss 1400], length 0  00:00:00.000241 AF IPv4 (two), length 44: (tos 0x0, ttl 63, id 28583, offset 0, flags [none], proto TCP (half-dozen), length 40)     My-WAN.31533 > 172.16.1.0.59372: Flags [.], cksum 0xc3ca (right), seq 1, ack 1, win 64400, length 0  00:00:00.003992 AF IPv4 (ii), length 205: (tos 0x0, ttl 63, id 28584, offset 0, flags [none], proto TCP (half-dozen), length 201)     My-WAN.31533 > 172.sixteen.1.0.59372: Flags [P.], cksum 0xc832 (right), seq one:162, ack 1, win 64400, length 161  00:00:00.302961 AF IPv4 (2), length 205: (tos 0x0, ttl 63, id 28585, offset 0, flags [none], proto TCP (6), length 201)     My-WAN.31533 > 172.16.1.0.59372: Flags [P.], cksum 0xc832 (right), seq ane:162, ack 1, win 64400, length 161  00:00:00.394904 AF IPv4 (2), length 205: (tos 0x0, ttl 63, id 28586, start 0, flags [none], proto TCP (6), length 201)     My-WAN.31533 > 172.16.i.0.59372: Flags [P.], cksum 0xc832 (correct), seq 1:162, ack 1, win 64400, length 161  00:00:00.699004 AF IPv4 (2), length 205: (tos 0x0, ttl 63, id 28587, commencement 0, flags [none], proto TCP (half-dozen), length 201)     My-WAN.31533 > 172.16.1.0.59372: Flags [P.], cksum 0xc832 (correct), seq i:162, ack i, win 64400, length 161  00:00:00.589524 AF IPv4 (2), length 56: (tos 0x2,ECT(0), ttl 63, id 36468, starting time 0, flags [none], proto TCP (6), length 52)     My-WAN.60033 > 172.sixteen.2.0.59372: Flags [Run up], cksum 0x442d (correct), seq 3544223184, win 62720, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0  00:00:00.013934 AF IPv4 (2), length 48: (tos 0x2,ECT(0), ttl 254, id 9436, showtime 0, flags [DF], proto TCP (half dozen), length 44)     172.sixteen.ii.0.59372 > My-WAN.60033: Flags [S.], cksum 0x3e54 (correct), seq 3004006065, ack 3544223185, win 4200, options [mss 1400], length 0  00:00:00.000178 AF IPv4 (2), length 44: (tos 0x0, ttl 63, id 36469, commencement 0, flags [none], proto TCP (vi), length 40)     My-WAN.60033 > 172.16.2.0.59372: Flags [.], cksum 0x6aac (correct), seq i, ack 1, win 64400, length 0  00:00:00.005371 AF IPv4 (2), length 497: (tos 0x0, ttl 63, id 36470, offset 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.16.2.0.59372: Flags [P.], cksum 0x62af (right), seq i:454, ack i, win 64400, length 453  00:00:00.385924 AF IPv4 (ii), length 497: (tos 0x0, ttl 63, id 36471, offset 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.16.2.0.59372: Flags [P.], cksum 0x62af (correct), seq ane:454, ack i, win 64400, length 453  00:00:00.304076 AF IPv4 (2), length 205: (tos 0x0, ttl 63, id 28593, offset 0, flags [none], proto TCP (6), length 201)     My-WAN.31533 > 172.16.ane.0.59372: Flags [P.], cksum 0xc832 (correct), seq i:162, ack 1, win 64400, length 161  00:00:00.095936 AF IPv4 (2), length 497: (tos 0x0, ttl 63, id 36472, offset 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.16.2.0.59372: Flags [P.], cksum 0x62af (correct), seq 1:454, ack i, win 64400, length 453  00:00:00.218016 AF IPv4 (2), length 44: (tos 0x0, ttl 254, id 10875, offset 0, flags [DF], proto TCP (vi), length twoscore)     172.16.one.0.59372 > My-WAN.31533: Flags [R.], cksum 0xbf57 (correct), seq i, ack i, win 0, length 0  00:00:00.476972 AF IPv4 (2), length 497: (tos 0x0, ttl 63, id 36477, offset 0, flags [none], proto TCP (vi), length 493)     My-WAN.60033 > 172.sixteen.ii.0.59372: Flags [P.], cksum 0x62af (correct), seq one:454, ack ane, win 64400, length 453  00:00:01.204971 AF IPv4 (two), length 497: (tos 0x0, ttl 63, id 36480, offset 0, flags [none], proto TCP (6), length 493)     My-WAN.60033 > 172.16.2.0.59372: Flags [P.], cksum 0x62af (correct), seq 1:454, ack ane, win 64400, length 453  00:00:00.323059 AF IPv4 (2), length 44: (tos 0x0, ttl 254, id 13669, start 0, flags [DF], proto TCP (6), length xl)     172.16.ii.0.59372 > My-WAN.60033: Flags [R.], cksum 0x6639 (right), seq 1, ack i, win 0, length 0                              

Here's a minor output of that control.

The weird thing is, when I do canyouseeme, it shows me another public IP than what is shown in the WAN interface on my pfSense box.
Both are public IPs, and I tested both, and now they say closed.

here

@undertaker666 I merely see pppoe0, where'south pflog0?

@lolipoplo pflog0 was empty, no matches.

@undertaker666

pfsense has logging on for all of the default block/pass up rules

If pflogs is empty, this probably means your port forwarding is working provided y'all do not take silent block/reject rules.

one more sanity check, go to your associated pass rules for nat and enable logging, then listen to pflog0 over again to make sure they are matched

@lolipoplo Still empty, and I could meet almost nothing hits the rule in the auth screen as well.

Even though I ran a check from an online service to see if information technology's open or not, it did not register, and the test came dorsum as closed.

Something is very weird here. I already did such a cheque before that returned open, so I'one thousand not sure what happened.

@lolipoplo

                              00:00:39.893213 dominion 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 39453, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 123.139.94.xl.16379: [udp sum ok] UDP, length 104  00:11:15.697052 dominion 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 41593, starting time 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 123.139.94.40.16379: [udp sum ok] UDP, length 104  01:27:00.579015 rule 51/0(friction match) [ridentifier 1000000119]: cake in on em1: (tos 0x0, ttl 64, id 24615, first 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62214: [udp sum ok] UDP, length 104  00:00:00.296683 dominion 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 24616, first 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62224: [udp sum ok] UDP, length 104  00:14:59.783329 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 63138, starting time 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62214: [udp sum ok] UDP, length 104  00:04:14.623627 dominion 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 63139, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.52601: [udp sum ok] UDP, length 104  00:x:46.028208 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 21564, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.i: [udp sum ok] UDP, length 104  00:00:00.290588 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 21565, showtime 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62224: [udp sum ok] UDP, length 104  00:00:01.600105 rule 51/0(friction match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 21566, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62224: [udp sum ok] UDP, length 104  00:14:58.004355 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 6150, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.52601: [udp sum ok] UDP, length 104  00:00:00.162623 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 6151, commencement 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.1: [udp sum ok] UDP, length 104  00:00:00.154916 dominion 51/0(friction match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 6152, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62386: [udp sum ok] UDP, length 104  00:00:01.225057 rule 51/0(match) [ridentifier 1000000119]: cake in on em1: (tos 0x0, ttl 64, id 6153, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62320: [udp sum ok] UDP, length 104  00:xiv:58.611751 dominion 51/0(match) [ridentifier 1000000119]: cake in on em1: (tos 0x0, ttl 64, id 47222, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62320: [udp sum ok] UDP, length 104  00:00:01.804954 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 47223, offset 0, flags [none], proto UDP (17), length 132)     192.168.55.100.59372 > 45.190.158.201.62386: [udp sum ok] UDP, length 104  00:33:32.433578 rule 4/0(match) [ridentifier 1000000103]: cake in on pppoe0: (tos 0x28, ttl 110, id 63739, commencement 0, flags [none], proto TCP (6), length 52)     154.16.174.207.59372 > My-WAN-IP.54296: Flags [Southward], cksum 0x05da (correct), seq 3626588183, win 65142, options [mss 1287,nop,wscale 8,nop,nop,sackOK], length 0  00:00:01.010321 rule iv/0(match) [ridentifier 1000000103]: block in on pppoe0: (tos 0x28, ttl 110, id 63740, offset 0, flags [none], proto TCP (vi), length 52)     154.sixteen.174.207.59372 > My-WAN-IP.54296: Flags [S], cksum 0x05da (correct), seq 3626588183, win 65142, options [mss 1287,nop,wscale 8,nop,nop,sackOK], length 0  00:00:02.000693 rule iv/0(match) [ridentifier 1000000103]: block in on pppoe0: (tos 0x28, ttl 110, id 63741, showtime 0, flags [none], proto TCP (6), length 52)     154.16.174.207.59372 > My-WAN-IP.54296: Flags [S], cksum 0x05da (correct), seq 3626588183, win 65142, options [mss 1287,nop,wscale 8,nop,nop,sackOK], length 0  00:07:xx.160301 rule 4/0(friction match) [ridentifier 1000000103]: block in on pppoe0: (tos 0x2a,ECT(0), ttl 113, id 17567, offset 0, flags [none], proto TCP (6), length 52)     188.132.209.91.59372 > My-WAN-IP.38535: Flags [SEW], cksum 0x7a03 (right), seq 4200447135, win 64240, options [mss 1400,nop,wscale 8,nop,nop,sackOK], length 0  00:00:06.000334 rule four/0(friction match) [ridentifier 1000000103]: cake in on pppoe0: (tos 0x28, ttl 113, id 17573, offset 0, flags [none], proto TCP (vi), length 52)     188.132.209.91.59372 > My-WAN-IP.38535: Flags [S], cksum 0x7ac3 (right), seq 4200447135, win 64240, options [mss 1400,nop,wscale 8,nop,nop,sackOK], length 0                          

This is after I left information technology for a whole night to run.

johnsonsuccionoth.blogspot.com

Source: https://forum.netgate.com/topic/170615/can-t-get-port-forward-to-work-correctly/23

Share this post