I doubt it's a hardware issue causing memory use like that.

Yes almost certainly port forwards. Since this is a routed subnet you don't actually need VIPs at all, just outbound NAT rules. However it's logically easier to see what's happening if you add them and it allows for forwards later if required.

@markchen Awesome, glad that solved it!

@gregeeh said in Can't update to 2.7:

[2.6.0-RELEASE][admin@pfSense.localdomain]/root: pkg info -x pfsense
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/sbin/pkg not found

This is an expected error after 2.7 was release. It should not cause any problem for normal operation in pfSense where all functions use pkg-static to allow for it.

Steve

@johnpoz Oh, I believe you. All I can say is it stopped working for me. I thought Comcast had blacklisted me because sometimes when I'm futzing around I create a flood of alerts, sending one to Comcast, one to Outlook.com and one to ATT.net. IIRC, there were instructions on the notifications page previously saying to use commas and no spacing between addresses. 🤷 No problema.

Sorry for not being clear, not only do I not have 2 minutes these days but don't want to change anything on the router while dealing with urgent medical phone calls that go through the pfsense router. When it blows over I plan to test turning the auto rules off, and possible test an inverse rule I mentioned above. Just now is not a good time to do anything. Thanks again to all who posted options, just wanted let you know I read and appreciate the posts.

I'd consider the UPS an "older" model, but not ancient. I'm using a 240v "Double Conversion Online" SmartUPS RT SURTD5000VA, so in theory there is near zero fluctuation or spikes when transferring. It has an additional external battery pack, and I then use an APC SURT003 isolation and step-down transformer for 120v devices, which leads to a couple PDUs, and then feeds devices off of that. There are other PDUs off of the main unit that feed 240v devices.

Not much to configure on this device other than upper and lower bypass ranges, but those only apply when bypass mode is utilized, which I never do. Output always hovers around +-1 at 240v, same with 60hz.

Nothing else connected to the 3100, just power, wan, and lan1.

@gniting
Like running two DNS server process on the same address same port.
Or web servers.
IMHO : that's pretty broken.

@gniting said in Run two services on the same port?:

SO_REUSEADDR and SO_REUSEPORT

IFAIK both process should also support port sharing .... maybe. Not sure if Avahi does this. Guess not.

As follow up,
the changes proposed in the topic about proxmox seems to work. The firewall has been up for 60 days without an issue.

Tyvm!

So I am having a very similar issue trying to change my 6100 MAX to become a transparent firewall between my AT&T Fiber Gateway and my UDM-SE. This forum post is very close to what I’m trying to do, but it doesn’t seem to work for me nor did the OP respond if he/she ever got it working. I’ve also watched Tom Lawrence’s YouTube videos on this, but in his example he’s not including his WAN interface - only two LAN interfaces.

Note that I have been using my 6100 MAX in front of my UDM-SE in a dual-NAT scenario primarily for much better control over DNS filtering (pfBlocker) and Snort (IPS: WAN, IDS: LAN). This has worked flawlessly for almost a year with no issues (although doing port forwards can be kind of tricky), and no problems up to this point. For the sake of masking my real public IPs, please just assume that 99.99.99.99/29 is my public IP block (AT&T actually provides a /32 and a /29 for a total of 6 usable public IPs).

—————————————————————————

Current Deployment and Configuration

[Internet] ----- [AT&T Gateway] ----- [pfSense] ----- [UDM-SE]

AT&T Gateway (99.99.99.99/29) WAN "IP passover" mode to pfSense (essentially just a modem and gateway)
AT&T Gateway (192.168.0.1/24) - LAN
pfSense (99.99.99.99/29) - WAN (via DHCP for primary /32 WAN IP plus additional /29 block configured as virtual IPs)
pfSense (10.0.0.1/24) - LAN
UDM-SE (10.0.0.2) - WAN IP via DHCP from pfSense
UDM-SE (10.0.1.1) - MGMT IP

Again, no problems whatsoever up to this point. I can get to all 3 management interfaces (AT&T/pfSense/UDM-SE) from my UniFi LAN without issue.

—————————————————————————

What I want to do is change my 6100 MAX to become a transparent firewall instead so I can get rid of dual-NAT scenario and manage my 6 public IPs on the UDM-SE instead.

Within pfSense, I have tried disabling NAT, creating a new bridge with both LAN/WAN (this also includes changing both System Tunables to member=0 and bridge=1 and setting the LAN and WAN interfaces to no IP address) and assigned it a management IP on the AT&T Gateway LAN. No dice getting to pfSense or AT&T gateway's web interfaces. No Internet connectivity at all. If I set both System Tunables to 0, everything works (minus any filtering of course). Once I turn the bridge tunable back to 1, I keep seeing default denies in the firewall log. I don't understand why because I temporarily have all interfaces firewall rules wide open for IPv4.


Proposed Deployment and Configuration:

[Internet] ----- [AT&T Gateway] ----- [pfSense] ----- [UDM-SE]

AT&T Gateway (99.99.99.99/29) WAN "IP passover" mode to UDM-SE (essentially just a modem and gateway)
AT&T Gateway (192.168.0.1/24) - LAN
pfSense with LAN/WAN configured as a bridge interface
UDM-SE WAN: (static /32 plus 99.99.99.99/29 as additional IPs)
UDM-SE LAN (10.0.1.1) - MGMT IP

I have scoured through so many forum posts and other websites for about 2 days trying to get this to work, but I keep having to revert back to my current setup (thank goodness for pfSense Plus boot environments). I should not have to configure any static routes since a transparent firewall should work without changing anything on the AT&T Gateway or UDM-SE. The proposed scenario obviously works perfectly fine without the pfSense in the mix. So what is the proper way to do this? No matter what I try, I can’t seem to get this to work. Thanks.

@neiltiffin See this is precisely the issue, it's important to actually read into the vulnerabilities before just saying CVSS 9.8 it's the end of the world.

If you knew what the actual issue was, it's basically a non issue. No one should be exposing their firewall webGUI to the public internet anyway, or any untrusted network for that matter, it should be accessed over a VPN. The whole purpose of that general best practice advise is to avoid issues like this being a problem (which BTW basically every other firewall has had similar login related CVEs that were super bad, many worse than just brute force allowance) when they do pop up. While it's important for things like this to be fixed (and it is fixed) regardless, admins still need to practice best security advise.

Additionally, all this vuln lets you do is brute force without any restrictions, but if you're following another best practice and using good strong login credentials, it shouldn't matter anyway.

I also don't understand this: "at least one major vulnerability that went un-resolved in pfsense 2.6", so what you are saying is that something got fixed but since it wasn't fixed in the version you wanted it to be fixed in it's not ok? IDK what to tell you at that point.

IDK this is all seeming like a common internet post where someone wants attention so they just complain about stuff without really knowing what they're talking about.

Thanks to all for the support. Issue is resolved successfully with the following steps.

Created a new network ( different from LAN subnet ) in one of the unused port of the backup pfsense box.

Connected the laptop to this new port. Laptop gets an IP.

The backup pfsense WAN port is connected to the LAN of main pfsense box

Disabled LAN network on the backup pfsense box ( temporary )

Now the backup pfsense box can connect to internet.

Did the upgrade.

Disconnect WAN.

Enable the LAN network on the backup pfsense box ( We can leave the new network as is or disable it ).

Works well for my use case. Thanks again for the support!

@johnpoz

Hello, that's works, to resume,

i have to add a nat port and fixed the port on the Plex serveur

and now works

realy thanks to help me to found this

thanks all !!!

@stephenw10 Yes, that was the first time. I did not try using Google LDAP until after I upgraded to 23.05.1.

@stephenw10 I work with RTSP streams with various brands all over US. If he port forwarded everything correctly it should work without any problems.

I'm assuming that was a typo.

Seeing fragmented packets like that implies some type of MTU mismatch so I'd look for that. Perhaps something changed on your WAN. Or maybe you added a VLAN the traffic is using.

@buzzhussman but where does that say that traffic on host A would be seen by some box on host B.

I could guess its possible that traffic coming in from the real network on host A from some vm on host B might be seen by all devices on the vswitch on host A.. But then again that only might happen for traffic that is local to the vswitch on host A..

If you want to see traffic from some VM on host B talking to pfsense on host A - why do you not just sniff on pfsense itself?