You're welcome, glad to be of help.

@modesty
It's basically not a good idea to expose a NAS to the internet at all. However, that's your decision.

I suspect the issue won't rather be the NAS itself than the firewall rule or the port. I guess, the Synology might block access from IPs outside of its own subnet.
You will have to allow that on the NAS itself.

I take it all back. This is nothing to do with NAT. After purchasing a second static IP address and creating a set of completely stateless rules (a story in itself) I find that the problem still occurs. Rapidly opening many connections, to many destinations causes huge spikes in packet loss and latency which correlate only to a rise in system CPU usage. Though this rise is only from a base level of ~1% utilization up to a maximum of 7% utilization, so it should not itself be causing the issue.

I can't find any other metric that is even remotely stressed.

@furom

Hi, got a similar problem here.

What work:
Setting a single ip/32 in my NAT -forward as source
Setting the an alias which only have one entry.

Doesn't work:
Alias with multiple hosts or networks(/32)

Also got a port alias connected to this NAT. 21, 8096,49152-50152

Can't figure out why I can't use an source alias with multiple entries on this NAT.

Any suggestions?

@viragomann
These scenarios don't work, but I also think that it's reloated to my config because the translated network matches an existing network.

I'm going to make some adjustments to my config to try again friday.

Thanks for the leads and the help.👍

@viragomann You're totally right !

The gateway was marked as down but ping to 1.1.1.1 from it works.
I changed the monitor IP, the gateway goes to UP and the traffic is OK

Many many thanks ;)

@lolipoplo

00:00:39.893213 rule 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.40.16379: [udp sum ok] UDP, length 104 00:11:15.697052 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 41593, offset 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(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 24615, offset 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 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 24616, 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:59.783329 rule 51/0(match) [ridentifier 1000000119]: block in on em1: (tos 0x0, ttl 64, id 63138, offset 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 rule 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:10: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.1: [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, 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:00:01.600105 rule 51/0(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, offset 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 rule 51/0(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]: block 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:14:58.611751 rule 51/0(match) [ridentifier 1000000119]: block 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]: block in on pppoe0: (tos 0x28, ttl 110, id 63739, offset 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:00:01.010321 rule 4/0(match) [ridentifier 1000000103]: block in on pppoe0: (tos 0x28, ttl 110, id 63740, offset 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:00:02.000693 rule 4/0(match) [ridentifier 1000000103]: block in on pppoe0: (tos 0x28, ttl 110, id 63741, offset 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:20.160301 rule 4/0(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 (correct), seq 4200447135, win 64240, options [mss 1400,nop,wscale 8,nop,nop,sackOK], length 0 00:00:06.000334 rule 4/0(match) [ridentifier 1000000103]: block in on pppoe0: (tos 0x28, ttl 113, id 17573, offset 0, flags [none], proto TCP (6), length 52) 188.132.209.91.59372 > My-WAN-IP.38535: Flags [S], cksum 0x7ac3 (correct), seq 4200447135, win 64240, options [mss 1400,nop,wscale 8,nop,nop,sackOK], length 0

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

Changing the setting from Router to AP was key: thanks for noting it.

PS5 sees NAT2 now. There was great rejoicing.

@8318587e-acc4-4a8c-a275-d1e5c5a684a8-image.png

This seems to be the rule that allow the connection...

@j-lanham You're welcome. Also after (re)installing pfB you might need to run an update to generate the aliases.

I am not sure why there are two packages. I suspect the -devel started out as "beta" but then everyone started using it, and now people would have to uninstall it to install the original. -devel version 2.x existed long before 3. The author has a Patreon site at http://pfblockerng.com/ but it doesn't really explain that.

Found the solution.

Go to outbound nat

Source:
Network 192.168.1.11/32
Destination:
Any - port 25

Translation:
Address:
1.1.1.8

Save and Apply

@viktor_g
Rules_RTK-2.jpg
NAT SDB SERVER rule works and exists
The problem is in the rule NAT TOiR

@nguser6947 said in Newbie port forwarding problem:

it is failing due to the default rule

You say this because you've looked at the firewall logs and you saw the incoming (WAN) traffic - with the correct (8096) port and correct "protocol TCP" being flagged as 'blocked' ?

I give you an example :

I have a Synology Diskstation in my LAN, it has IPv4 192.168.1.33 (RFC1918 of course).
I've created an alias for the device name "diskstation2", it resolves to 192.168.1.33.
I want to access my Diskstation using https://diskatation2.my-domain.tld:8080

I created a NAT rule :

3c428a1a-b625-4f10-977d-9a971db2e971-image.png

The 'destination' is the firewall macro WAN Address, as my WAN is is always part of WAN address. The day my WAN IP changes, my rule still works.

I want to reach my diskskation on port 8080, so "Destination port range" is set to 8080.

The traffic that comes in and matches WAN Address & port 8080 should go to :

Redirect target IP : I entered the Alias "diskstation2", I could also enter "192.168.1.30".
And the destination port : my diskstation web server listens on "443", it's using TLS.

I Save.

I have a NAT rule :

b9a38f8a-b0c8-4b69-a812-ea43c0b161da-image.png

I checked the auto created WAN firewall rule :

a7ab50e0-b8d0-4256-925b-404c45452f7f-image.png

I tested with my phone ( with Wifi shut down !! ) , and entered :

https://diskatation2.my-domain.tld:8080

I saw the main web page of the web server of my diskstation2.

I also saw :

b995333c-91b4-438e-8378-a00fc2c2ce60-image.png

which means that the WAN rule was used / matches incoming traffic. That was me testing the access with my phone..

If needed, abuse the pfSense documentation, like Port Forwards. Port forwarding or port NATting or, more correct, PATting, hasn't changed since 1995. Every Home/business router/firewall needs the same inputs. pfSEnse seems to be diffrent but check for yourself : you have to enter 4 things, and your good. The rest of the option are 'special cases'. The day you need them, you'll know they are there.
Also : I copied all the images without the need of masking something. The correct use of aliases and firewall macros make rules maintenance easy : It becomes a "set it and forget it" which means I had to look up the pfSense NAT doc, as I tend to forget things. I do not use NAT rules any more, only a VPN access which is just a firewall rule, no NAT). Exposing internal devices in a company network is a big no no (imho). This said : this is also valid for you : now your 192.168.1.250 becomes part of your network security. Keep that in mind.

@johnpoz

Yes, that was what I thought, and the question initially was regarding why it was not working. But I've found the problem now. I've set it, in the general setting, but NAT Reflection was set individually on each NAT rule. So changes here had no real affect.

Thanks a lot for your time.

@rsherga
In the OpenVPN client settings check "Don't pull routes" to permit the client to set the default route.

Assign an interface to the vpn client instance and enable it if you didn't already.
Then add a policy routing firewall rule to the internal interface. Enter the source IP or an alias for multiple if you want to specify. At destination leave the address at any and enter the destination port range.
Expand the advanced options and select the VPN gateway.
Put this rule to the top of the rule set so that it matches first.

I assume, you your outbound NAT is already set to work with the VPN.

To verify that the packets go out on the VPN interface, you can sniff the traffic using the packet capture tool on pfSense, while you try a connection to the concerned ports.

To ensure that nothing goes out to WAN you can add a floating block rule for direction out with Quick checked and state the ports in regards.

@viragomann

Thank you for the information, I did in fact have the P2 local network defined as the subnet on within the local LAN assuming the routing would have still sent the traffic across based on the destination IP and the routing table however that obviously didn't end up being the case. After changing the local network on the P2 from 192.168.1.0/24 to 0.0.0.0/0 the traffic started sending across the tunnel.

Thank you for the help!

@hulleyrob OK so it seems if I add a desitnation address I can save the rule however this was not the case before the upgrade.