@butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0: I have removed all non-essential packages. I have deleted and recreated the configuration multiple times. Have you tried the most hidden solution, the one that ctually always works : After a fresh install of pfSense : do nothing. Do not even change the password, just do plain nothing. Dont even run the the initial Wizard who makes pople think they have to give DNS servers because that is not the case. pfSense has a resolver, so it works out of the box. DNS will work out of the box. @butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0: My port forward to my DNS server isn't working. You have DNS resolver or forwarder on your LAN that you want to use ? Like a pi-hole or something ? Or do you have contract with 9.9.9.9 and they want all yuor private DNS requests ? Why do you think you need a DNS to forward to ? @butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0: I have three other port forwards that are still working, but not port 53. You forward port 53 from where to where ? You forward UDP, or TCP, or both ? @butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0: I run an external port scan DNS traffic is outbound, not inbound .... Right ? @butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0: I have double-checked with my ISP to make sure they're not blocking it. NO JOY. They wouldn't do that. Blocking your "UDP port 53" access to the Internet is nearly the same as cutting the WAN wire. @butlercn said in Port Forwarding DNS (only) is dead! v.2.6.0: Could there be an issue with the latest release (2.60)? Yep, No yoke. There is one. If you use the captive portal, and you use limiters ( see the many recent forum posts about this subject) then it might look like the resolver isn't working an ymore. This means : no more DNS. Work around : remove all limiters. If you use the captive portal : install [image: 1648817901133-8aaa7629-91fb-4536-8fc7-fe905df5835f-image.png] and apply the build in Captive portal patch.

@bmcneil There is nothing special with multi WAN, except the failover group. When your WAN are configured as DHCP client, the gateways are set automatically. Otherwise with static IP state the gateway in the interface settings. For the failover group go to System > Routing > Gateway Groups and create a new group wherein you set the preferred gateway as Tier 1 and the second as Tier 2.The trigger level "member down" should fit your needs. State a name for the group and save the settings. Then go to the gateways tab and set the failover group as default gateway and save this. The proper outbound NAT rule should be added automatically by pfSense for both WANs, if the NAT is in automatic mode. With this settings you should already have internet access from inside your network over both WANs. For accessing your pfSense from the internet in case of a failover you have to switch the WAN IP on the client side. For instance you can use DynDNS which can be updated with the actual working WAN IP by pfSense. A VPN client like OpenVPN is also capable to switch the server IP itself if one is not responding. So you can also use static IP or host names here.

@kilogica said in Reach LAN from WAN through ISP router and VPN: Otherwise, could it be safer if I'll leave the router IP out of the rule? As there is no need to give the router (or the ISP coming in through it) any access to your network that's a good decision in my opinion. If I understood the basics, masquerading makes all the packets forwarded as they're coming from my ISP router IP, if I block the access to the LAN behind pfSense to that specific IP it may be good, right? This all depends on how your router works, if it does masquerading on inbound traffic or not. If it does there should be an option to disable it, but I don't know. Imagine it does, then the block rule would block forwarded VPN traffic as well. So you will have configure your rules in a proper order to pass what you need and block the rest. So just check out if the router does masquerading. Forward traffic to pfSense WAN IP. Then start a packet capture on pfSense WAN (Diagnostic > Packet Capture) and trigger a traffic from outside.

@keyser Thanks for that! I think I know now which way to go. Will do the testing next week in my Lab before changing the customers configuration.

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.

@[image: 1647199239426-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.