NAT not opening on custom Ports

RyanH

@rico So how would I go about looking at this? Granted i'm a total noob but I want to get a better understanding of PFSense.

0_1544363515915_b265bbad-bc51-49d2-b419-93fa4765e81b-image.png

Rico

Your target 10.11.0.5 machine is using pfSense 10.11.0.1 as gateway right?
What can you see in the Logs about this connection?
Also show some screenshot of your Firewall Rules.

-Rico

RyanH

@rico said in NAT not opening on custom Ports:

Your target 10.11.0.5 machine is using pfSense 10.11.0.1 as gateway right?
What can you see in the Logs about this connection?
Also show some screenshot of your Firewall Rules.

-Rico

PEBKAC Time. Where can I find the logs? I can get into the terminal via my second screen as its currently hooked in so If I need to shell anything I can.

Dec 9 13:56:37 WAN Default deny rule IPv4 (1000000103)

I see this against it?

Derelict

You see those logs for what traffic? Please don't truncate/obfuscate anything. You left off part we need to see.

If you are getting "Connection Refused" it is not coming from pfSense unless you specifically set up Reject rules instead of Block rules.

A "Connection Refused" message means something received the SYN and replied with a RST. pfSense will not do that unless the traffic is hitting a Reject rule which is not anywhere in the default configuration.

Packet capture on WAN for the traffic to TCP port 27015. Attempt a connection. See what is there.

Then packet capture on LAN (or whatever interface 10.11.0.5 is on) for traffic to TCP port 27015 and attempt another connection. What is there?

Just about every guide out there will have you using auto-generated rules for the WAN interface instead of NAT firewall rule type Pass. Can you elaborate on why you chose to do it differently?

RyanH

@derelict said in NAT not opening on custom Ports:

You see those logs for what traffic? Please don't truncate/obfuscate anything. You left off part we need to see.

If you are getting "Connection Refused" it is not coming from pfSense unless you specifically set up Reject rules instead of Block rules.

A "Connection Refused" message means something received the SYN and replied with a RST. pfSense will not do that unless the traffic is hitting a Reject rule which is not anywhere in the default configuration.

Packet capture on WAN for the traffic to TCP port 27015. Attempt a connection. See what is there.

Then packet capture on LAN (or whatever interface 10.11.0.5 is on) for traffic to TCP port 27015 and attempt another connection. What is there?

Just about every guide out there will have you using auto-generated rules for the WAN interface instead of NAT firewall rule type Pass. Can you elaborate on why you chose to do it differently?

This is with a rule in place and still it shows as closed. That was tested via Yougetsignal

08:44:57.926213 AF IPv4 (2), length 57: (tos 0x0, ttl 116, id 7393, offset 0, flags [none], proto UDP (17), length 53)
    147.147.21.121.55058 > 90.255.228.195.27015: [udp sum ok] UDP, length 25
08:44:59.616503 AF IPv4 (2), length 64: (tos 0x0, ttl 56, id 27812, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45066 > 90.255.228.195.27015: Flags [S], cksum 0xaefc (correct), seq 19903264, win 14600, options [mss 1460,sackOK,TS val 1226039172 ecr 0,nop,wscale 8], length 0
08:44:59.616989 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 37, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45066: Flags [R.], cksum 0x786d (correct), seq 0, ack 19903265, win 0, length 0
08:44:59.785753 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 36926, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45067 > 90.255.228.195.27015: Flags [S], cksum 0x8093 (correct), seq 2466074512, win 14600, options [mss 1460,sackOK,TS val 1226039214 ecr 0,nop,wscale 8], length 0
08:44:59.786291 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 38, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45067: Flags [R.], cksum 0x4a2e (correct), seq 0, ack 2466074513, win 0, length 0
08:44:59.952469 AF IPv4 (2), length 64: (tos 0x0, ttl 56, id 41837, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45069 > 90.255.228.195.27015: Flags [S], cksum 0x58a0 (correct), seq 2376039605, win 14600, options [mss 1460,sackOK,TS val 1226039256 ecr 0,nop,wscale 8], length 0
08:44:59.953007 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 39, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45069: Flags [R.], cksum 0x2265 (correct), seq 0, ack 2376039606, win 0, length 0
08:45:00.688489 AF IPv4 (2), length 64: (tos 0x0, ttl 55, id 751, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45071 > 90.255.228.195.27015: Flags [S], cksum 0xff54 (correct), seq 2154226303, win 14600, options [mss 1460,sackOK,TS val 1226039440 ecr 0,nop,wscale 8], length 0
08:45:00.689037 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 40, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45071: Flags [R.], cksum 0xc9d1 (correct), seq 0, ack 2154226304, win 0, length 0
08:45:00.858007 AF IPv4 (2), length 64: (tos 0x0, ttl 55, id 15703, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45072 > 90.255.228.195.27015: Flags [S], cksum 0x674c (correct), seq 483843565, win 14600, options [mss 1460,sackOK,TS val 1226039482 ecr 0,nop,wscale 8], length 0
08:45:00.858533 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 41, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45072: Flags [R.], cksum 0x31f3 (correct), seq 0, ack 483843566, win 0, length 0
08:45:01.026749 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 27857, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45073 > 90.255.228.195.27015: Flags [S], cksum 0x4f74 (correct), seq 2252049461, win 14600, options [mss 1460,sackOK,TS val 1226039524 ecr 0,nop,wscale 8], length 0
08:45:01.027325 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 42, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45073: Flags [R.], cksum 0x1a45 (correct), seq 0, ack 2252049462, win 0, length 0
08:45:01.800016 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 39605, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45076 > 90.255.228.195.27015: Flags [S], cksum 0x6966 (correct), seq 2091285267, win 14600, options [mss 1460,sackOK,TS val 1226039718 ecr 0,nop,wscale 8], length 0
08:45:01.801066 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 43, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45076: Flags [R.], cksum 0x34f9 (correct), seq 0, ack 2091285268, win 0, length 0
08:45:01.968487 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 59277, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45077 > 90.255.228.195.27015: Flags [S], cksum 0x7cbf (correct), seq 3721922141, win 14600, options [mss 1460,sackOK,TS val 1226039760 ecr 0,nop,wscale 8], length 0
08:45:01.969043 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 44, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45077: Flags [R.], cksum 0x487c (correct), seq 0, ack 3721922142, win 0, length 0
08:45:02.136984 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 2651, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45078 > 90.255.228.195.27015: Flags [S], cksum 0x8ed2 (correct), seq 3864390561, win 14600, options [mss 1460,sackOK,TS val 1226039802 ecr 0,nop,wscale 8], length 0
08:45:02.137434 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 45, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45078: Flags [R.], cksum 0x5ab9 (correct), seq 0, ack 3864390562, win 0, length 0
08:45:03.155493 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 37631, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45083 > 90.255.228.195.27015: Flags [S], cksum 0x7cde (correct), seq 1927376903, win 14600, options [mss 1460,sackOK,TS val 1226040056 ecr 0,nop,wscale 8], length 0
08:45:03.155870 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 46, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45083: Flags [R.], cksum 0x49c3 (correct), seq 0, ack 1927376904, win 0, length 0
08:45:03.305254 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 38993, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45084 > 90.255.228.195.27015: Flags [S], cksum 0x1cda (correct), seq 3346430799, win 14600, options [mss 1460,sackOK,TS val 1226040094 ecr 0,nop,wscale 8], length 0
08:45:03.305808 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 47, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45084: Flags [R.], cksum 0xe9e4 (correct), seq 0, ack 3346430800, win 0, length 0
08:45:03.475493 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 7736, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45086 > 90.255.228.195.27015: Flags [S], cksum 0x0a98 (correct), seq 1466563953, win 14600, options [mss 1460,sackOK,TS val 1226040137 ecr 0,nop,wscale 8], length 0
08:45:03.476000 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 48, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45086: Flags [R.], cksum 0xd7cd (correct), seq 0, ack 1466563954, win 0, length 0
08:45:04.169504 AF IPv4 (2), length 64: (tos 0x0, ttl 55, id 15604, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45090 > 90.255.228.195.27015: Flags [S], cksum 0x8f55 (correct), seq 4033339139, win 14600, options [mss 1460,sackOK,TS val 1226040311 ecr 0,nop,wscale 8], length 0
08:45:04.169997 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 49, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45090: Flags [R.], cksum 0x5d39 (correct), seq 0, ack 4033339140, win 0, length 0
08:45:04.338289 AF IPv4 (2), length 64: (tos 0x0, ttl 55, id 49675, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45092 > 90.255.228.195.27015: Flags [S], cksum 0x981f (correct), seq 2689279531, win 14600, options [mss 1460,sackOK,TS val 1226040352 ecr 0,nop,wscale 8], length 0
08:45:04.339387 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 50, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45092: Flags [R.], cksum 0x662c (correct), seq 0, ack 2689279532, win 0, length 0
08:45:04.507499 AF IPv4 (2), length 64: (tos 0x0, ttl 54, id 47186, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45094 > 90.255.228.195.27015: Flags [S], cksum 0x9e90 (correct), seq 1673485337, win 14600, options [mss 1460,sackOK,TS val 1226040395 ecr 0,nop,wscale 8], length 0
08:45:04.508075 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 51, offset 0, flags [DF], proto TCP (6), length 40)
    90.255.228.195.27015 > 198.199.98.246.45094: Flags [R.], cksum 0x6cc8 (correct), seq 0, ack 1673485338, win 0, length 0

Also found this

 	Dec 10 09:50:22 	WAN 	NAT Ark Server Query Port (1544431404) 	198.199.98.246:59196		10.11.0.5:27015		TCP:S
	Dec 10 09:50:22 	► LAN 	let out anything IPv4 from firewall host itself (1000002665) 	198.199.98.246:59196		10.11.0.5:27015		TCP:S

0_1544489414770_a94e1dad-b8c2-46d4-8691-ea7da516d6f3-image.png

Derelict

@ryanh said in NAT not opening on custom Ports:

08:44:59.616503 AF IPv4 (2), length 64: (tos 0x0, ttl 56, id 27812, offset 0, flags [DF], proto TCP (6), length 60)
198.199.98.246.45066 > 90.255.228.195.27015: Flags [S], cksum 0xaefc (correct), seq 19903264, win 14600, options [mss 1460,sackOK,TS val 1226039172 ecr 0,nop,wscale 8], length 0
08:44:59.616989 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 37, offset 0, flags [DF], proto TCP (6), length 40)
90.255.228.195.27015 > 198.199.98.246.45066: Flags [R.], cksum 0x786d (correct), seq 0, ack 19903265, win 0, length 0

The server is sending a RST - rejecting the connection. Check the logs there.

To be sure, do the same capture on the inside interface.

Again, check (really check) everything here:

https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html

it is pretty much invariably something on that list.

RyanH

@derelict said in NAT not opening on custom Ports:

@ryanh said in NAT not opening on custom Ports:

08:44:59.616503 AF IPv4 (2), length 64: (tos 0x0, ttl 56, id 27812, offset 0, flags [DF], proto TCP (6), length 60)
198.199.98.246.45066 > 90.255.228.195.27015: Flags [S], cksum 0xaefc (correct), seq 19903264, win 14600, options [mss 1460,sackOK,TS val 1226039172 ecr 0,nop,wscale 8], length 0
08:44:59.616989 AF IPv4 (2), length 44: (tos 0x0, ttl 127, id 37, offset 0, flags [DF], proto TCP (6), length 40)
90.255.228.195.27015 > 198.199.98.246.45066: Flags [R.], cksum 0x786d (correct), seq 0, ack 19903265, win 0, length 0

The server is sending a RST - rejecting the connection. Check the logs there.

To be sure, do the same capture on the inside interface.

Again, check (really check) everything here:

https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html

it is pretty much invariably something on that list.

So finds report that the server stream lines the ARK ports over the network without glitches... I can see the server on the lan list but my friends who test it outside of my network cannot see at all.

Firewalls in both virtual and host machines are turned off leaving only the PFSense to handle ins and outs.

I use a Openreach Modem which goes directly from LAN1 into my dual network card in the PFSense box which connects the PPPoE. The Modem isn't hacked its stock standard, i've checked with my ISP and they aren't blocking the ports.

Nat reflections is set to NAT + Proxy, I only have LAN and WAN. I've deleted and remade NAT Portforward including rules. I'm literally at the end.

johnpoz

@ryanh said in NAT not opening on custom Ports:

90.255.228.195.27015 > 198.199.98.246.45094: Flags [R.]

Your using 90.255 on your lan? Or you sniffed on your WAN??

What is the IP of this server your forwarding too? RFC1918 what??? Looks like 10.11.0.5

This is LAN network right... Then SNIFF, packet capture on pfsense LAN interface... Pfsense would not sent a RST unless you had a REJECT rule setup be it on wan or floating..

Post your wan, lan and floating firewall rules tab.. And the sniff on your LAN side interface on pfsense and we will help you figure out where your problem is... Since you seem incapable of following the simple instructions on troubleshooting given in the guide.

RyanH

This post is deleted!

RyanH

@johnpoz

0_1544547025301_37a8be21-ceab-4a30-bd51-6638103b322a-image.png

0_1544547038427_f5c2ad04-4bb0-490e-a95e-918123443ca3-image.png

0_1544547538921_f9694dac-2931-46b1-8da1-acc822476756-image.png

16:58:20.698354 90:e2:ba:06:47:19 > 00:15:5d:00:39:0a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 53, id 34225, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45870 > 192.168.1.5.7777: Flags [S], cksum 0xe15e (correct), seq 3692619266, win 14600, options [mss 1460,sackOK,TS val 1255039923 ecr 0,nop,wscale 8], length 0
16:58:21.695091 90:e2:ba:06:47:19 > 00:15:5d:00:39:0a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 53, id 34226, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45870 > 192.168.1.5.7777: Flags [S], cksum 0xe064 (correct), seq 3692619266, win 14600, options [mss 1460,sackOK,TS val 1255040173 ecr 0,nop,wscale 8], length 0
16:58:21.696346 90:e2:ba:06:47:19 > 00:15:5d:00:39:0a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 55, id 59506, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45875 > 192.168.1.5.7777: Flags [S], cksum 0xc983 (correct), seq 1276808412, win 14600, options [mss 1460,sackOK,TS val 1255040174 ecr 0,nop,wscale 8], length 0
16:58:22.696119 90:e2:ba:06:47:19 > 00:15:5d:00:39:0a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 55, id 59507, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45875 > 192.168.1.5.7777: Flags [S], cksum 0xc889 (correct), seq 1276808412, win 14600, options [mss 1460,sackOK,TS val 1255040424 ecr 0,nop,wscale 8], length 0
16:58:22.697832 90:e2:ba:06:47:19 > 00:15:5d:00:39:0a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 55, id 10376, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45880 > 192.168.1.5.7777: Flags [S], cksum 0x7016 (correct), seq 3829681440, win 14600, options [mss 1460,sackOK,TS val 1255040424 ecr 0,nop,wscale 8], length 0
16:58:23.696111 90:e2:ba:06:47:19 > 00:15:5d:00:39:0a, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 55, id 10377, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.45880 > 192.168.1.5.7777: Flags [S], cksum 0x6f1c (correct), seq 3829681440, win 14600, options [mss 1460,sackOK,TS val 1255040674 ecr 0,nop,wscale 8], length 0

RyanH

@johnpoz

also

17:10:45.632826 IP 192.168.1.1.32454 > 192.168.1.5.7777: tcp 0
17:10:48.646663 IP 192.168.1.1.32454 > 192.168.1.5.7777: tcp 0
17:10:51.915662 IP 192.168.1.1.32454 > 192.168.1.5.7777: tcp 0
17:10:55.162909 IP 192.168.1.1.32454 > 192.168.1.5.7777: tcp 0

Derelict

OK so 192.168.1.5 isn't responding.

RyanH

@derelict I don't get it, the firewall is off... 1.5 is the VM running via hyper V

Derelict

All we can see is the SYN packets are sent to 192.168.1.5 port 7777 and there is no response. It's something in either your infrastructure or on that host itself. It's not the firewall. The firewall is forwarding the traffic as instructed.

RyanH

@derelict Thing about it is, it works perfectly find on a normal router (Zyxel), nothings changed on the server itself... ?

Derelict

Well, the SYN is sent and there is no response. Nothing to do with the firewall there.

Check (really check) everything here:

https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html

Grimson

Is this a windows VM? If yes it probably detected that the MAC of the default gateway changed and switched the network type to public which then turns parts of the firewall back on. So really check your stuff.

johnpoz

^ exacltly! router 1 with mac xyz.. firewall set to private or turned off... Router 2 (pfsense) put in place new mac ABC... windows says oh better default to public network firewall ON..

Here is the thing... you sent SYN to mac xyz... Why your host doesn't answer has zero to do with pfsense..

Only thing you can do on pfsense here is validate that mac xyz is actually your machine your wanting to send too.. If correct mac, then the problem is somewhere on the wire between pfsense and the host.. Pfsense did its job, it put the traffic on the wire.. Pfsense as nothing to do until it sees the return traffic.

This is the part that gets frustrating

I followed it before hand.

Clearly you didn't because if you did you would have already done this sniff and found that pfsense sent the traffic on and the box didn't answer..

RyanH

@johnpoz I get the frustration BUT

I have done EXACTLY what i did to get my server RDP working. and it works! Did it with my main pc IT WORKS, I followed the exact same steps. I even made allowances in the windows firewall. Followed the exact same steps results? Connection failed.

Solve that one real quick -_-; because I stripped my entire network apart and put it back together piece by piece and yet I yeild the same results!? So believe me when I say The Frustration is mutual

Heres the funny part too. I did it to my machine WHICH i know replies and guess what... CONNECTION FAILED. I'm one firewall short of flipping a table here

Derelict

All pfSense can do is forward the traffic. That there is no response is because something inside is configured incorrectly for the task you desire it to perform..

I don't get what is so difficult to understand about that. How is something on the firewall supposed to conjur up a response from the target host?

What would you have us do for you?