You can do that using manual outbound NAT: https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#working-with-manual-outbound-nat-rules First you need to have those public IPs present on the firewall. So a public subnet that is routed to you be the ISP perhaps. Steve

The 1100 only has one NIC, mvneta0, and all interfaces are VLANs on that including WAN and LAN. Your new hardware probably has at least two NICs so you can add the VLANs to either. If it has 4 NICs you may only need VLANs 20 and 66. The other interfaces can be moved to real NICs. Steve

The redirect target IP on the port forward should be the internal server IP not the LAN address. I expect to see one port forward for each port unless they are all directing to the same internal IP in which case you could use a 1:1 NAT rule. Steve

@koenh This indicates that somewhere between the pfSense WAN interface, and what ever monitoring ip you are using, has some ugly packetloss. I would shift the monitoring ip back to "default" ... (the DHCP delivered default gateway) , and maybe change the network cable between the pfSense & the ISP Box. Your pfSense Wan IF is connected directly to the ISP box, correct ?? Maybe i'd power off/on the ISP Box, just to make a "fresh start" ... If it continues with packet loss between pfSense Wan and the ISP default gateway , i'd contact the ISP and explain the issue. Edit: V'man beat me to it /Bingo

I would not expect it to. Disabling NUT as a test is pretty easy though.

I don't find it paranoid or over the top to use a dedicated, offline system for managing your IT infrastructure considering the low prices for a Chromebook or similar. My diy nuclear reactor must stay secure... ;)

@viragomann They are all Realtek, damn them and their drivers. However I solved it by putting two NICs on another PC where at least there is an Intel NIC that I use for the LAN. How much time wasted for a PC that until a month ago was working without problems and in the last month has simply been turned off. Thanks a lot for the support.

@dennypage The power wasn't flickering, the power was out from 10p through 1a. The nut server is not configured to turn the UPS proactively so the UPS just shuts down once the battery is completely depleted a few minutes after every client was supposed to shut down ("low battery" when nut clients are being turned off is set to 10%). I understand the behavior in the log could be explained if the UPS turned the power to pfSense off and then back on between 22:52:05 and 22:52:13 but I don't think it was the case. Based on the timestamps alone it would seem pfSense went from shutdown to boot immediately while the system remained powered by the UPS.

@tquade to be honest port scanning the "world" could be less troublesome - than an isp customer complaining about another same isp customer But sure yeah probing the world not normally a good thing ;) To be honest many an isp should be filtering fellow customers from talking to fellow customers.. But forget getting in trouble or what you should be doing or not being doing to be a good netizen. I make sure no rfc1918 traffic leaks out my wan for sure.. Just doing my part to be a good netizen.. Rarely happens but now and then I typo a address or something.. I make sure that dns for my private domain never goes outbound as well - just no point in sending such traffic that isn't going to resolve.. What would be the point other then pure curiosity knowing that some fellow isp customer has ssh open, or running xyz as their router? What would you even do with that info? I would rather not waste my cpu cycles and bandwidth finding out that info in the first place - and just not send probes out my wan.. Now if he devices on pfsense wan this 192.168.8 network - and he wants to discovery his own devices on that network. Then going to have to look into making sure ntop only discovers 192.168.8/24 and not whatever his real wan is..

@stephenw10 Call quality is fine. I’ll have a look at the logs. Thanks!

@davewh Power cycling it fixed the problem. Thanks!

@mephmanx It took a lot of work but I was able to get through this.

Minimal. Somethings don't work well (or at all) behind double NAT. Mostly things that require NAT workarounds like UPnP. Has no impact on security (arguably improves it!) and performance impact is usually minimal as long as the upstream router does not restrict the throughput. Some SOHO routers have very limit state tables for example. Steve

Mmm, that's tough because generally that means one server process. So 10G is pretty much right out with pfSense.

@stephenw10 said in Bridge blocking.: Ah, OK. Yeah that should work. Just tried it, and it works flawlessly. Thanks.

@stephenw10 thank you very much! I am working on why my memory utilization went from 3-4 percent to 11-12 percent and growing. Once I collect and compare the top info for a few days I will seek more help. Thanks for the quick responses.

Do the gateways show as down?

Thank you all, it's solved !

Mmm, it's a known issue. It's ugly but harmless. You shouldn't ever manually edit the loader.conf file normally but you can remove the duplicates. Any loader value you need to set or unset should always be put in loader.conf.local. Steve