@slightlybeige said in IP address conflict on new install despite changing it?: The fault I'm more interested in is how changing the interface IP appeared to somehow NOT change the interface IP. Connecting to an Interface and changing the IP is time critical. I can't test it right, now, but I guess you wind up having a big green Apply button. Ones hitting that, there will be a message that states that pfSense changes LAN settings, and a browser redirect should activate in "20 seconds". After the delay, the GUI should work on 192.168.1.4. If you connected your new pfSense to early, some of your network devices might have 'sniffed' that another "192.168.1.1" device was present on the network, and things go haywire. Btw : when starting up a new pfSense, I always activate the console access. Serial if possible, if not keyboard/VGA and by SSH also. Maintenance related to the GUI itself, IP changing, etc, I don't use the browser that, I use the console.

Hmm, that is usually OK to have enabled but yeah I;d just leave it disabled if it's causing a problem. Steve

Concur with Stephenw10 here, complex is normally not the best choice.. Why can you not just route/firewall with pfsense - if your current edge device can not be put in modem/bridge mode so that pfsense gets public IP on its wan.. Then just double nat.. Much simpler setup! Than bridging..

@johnpoz The AirVPN guide has the Do not pull routes checked so that is what I do. I do override the VPN to allow Netflix to work and also my email server but that is it. I learned something today. Thanks guys. Much appreciated Randy

Yes we usually don't make CE installer images for patch releases but made an exception for 2.4.4p1 as there were a number of nasty bugs in 2.4.4 it fixed. Things that could prevent you easily updating. Another good place to check is here: https://docs.netgate.com/pfsense/en/latest/releases/versions-of-pfsense-and-freebsd.html Steve

Many thanks Steve! You're a genius! adding route-nopull worked. VLAN30 is clear to isp and VLAN20 on VPN and does not go outside when the VPN connection is dead. Problem sorted!! Thanks again!!

I'm pretty sure the VPN wasn't the problem. I built this box from scratch. My old firewall worked no issues. This problem only started occurring when I went to this version. I also posted my issue on a Pfsense Facebook forum and I had a couple people confirm they also had the same issue when they went to version 2.4.4 p2. Their fix was to revert back a level. That isn't the best option for me at this time. I'm not an expert but I'm far from a novice.

Realize this topic is rather old but just wanted to update it that I went ahead and ordered caps from mouser that matched the spec of the ones I pulled off the board and got the old Firebox running again! Was even able to get it booting off a hard drive. Really appreciate all the insight offered!

FYI- Looks like you set it to pull updates from the 2.5.0 development snapshots but didn't upgrade to 2.5.0.

Sorted now thanks to Support

They are normally generated if they are missing when you try to update. What actual error are you seeing? Steve

@JeGr As haproxy terminates the TCP connection in a socket, and the state of that socket is not sinked to the secondary haproxy node the TCP connection will break when a failover is performed. Stick-table content can be synced.. but the state of all socket-connections is not. @adam65535 As for configuration changes on a running haproxy this should not have much notable impact on http connections as it would ask the browser nicely to close existing http connections, and new TCP-connection can be made to the already running new haproxy instance. And the old process keeps serving connections until the hard-stop-timeout (its default on the pfSense package is 15 minutes) or it will stop when no connections remain. Long existing connections like for a database connection or a ssh session, yes those would eventually break.. Or you would need a stop timeout of like 24 hours or something.. but that gives a risk of running lots of haproxy processes simultaneously if several changes are made during a day, risks like out-of-memory then arise...

Again: Pick an addon card, read up what chipset/controller it's using for the RS232 port and then check whether it is supported by FreeBSD. The PCIe bus has nothing to do with it.

1225v3 is the CPU. https://ark.intel.com/content/www/us/en/ark/products/75461/intel-xeon-processor-e3-1225-v3-8m-cache-3-20-ghz.html The prebuilds usually have similar or slower CPUs no? Is ECC really needed for pfsense and if you claim Single thread is that badly needed do you have any actual data to back that up because for my house even the 3770 should be faster than anything else I currently have set up or could reasonably buy. Also what about the NICs? I heard there are issues with fake NICs and wondering on prices for NICs because I have to do the used/generic route.

@Boab said in adding new subnet to existing WAN: I think I may have resolved it still checking. Writing it up on the forum and having a meal/break clears your head. will report tomorrow. Show us how you did it, with screenshots! Jeff

Problem solved : It was the default gateway for IPv4. It was using the IPv6 gateway. I think the new version applies a more strict policy. ;)

Welp turns out this whole ordeal had nothing to do with Verizon or my ONT. I did the packet capture and the mystery device sending DHCP signals to the WAN was the pfSense box's own baseboard management controller. My board's BIOS has an option to disable the IPMI function which is supposed to disable BMC networking along with it, but evidently that doesn't work as explained, or is broken. And even though I'd never connected that network interface to anything, the BMC wants a DHCP lease. I logged into the IPMI GUI, set a static config, and I'm now nearing 24 hours of uninterrupted uptime. The 0.0.0.0:67 - 255.255.255.255:68 entries haven't shown up again in packet captures or the firewall logs. I'm very happy this was smoothed out and thank you @Derelict for the tip to look at the MAC addresses. @dtruesdale For anyone else in this situation, a few more tips: You can just set an IPMI address, netmask, and gateway in the BIOS. This is all that's really necessary so you don't actually need expose the BMC to the network. If you fully configure IPMI and intend to leave it network-accessible, you'll of course want to change the default ADMIN/ADMIN username and password. Through significantly more trial and error than it should have taken, I found that even the latest version of my board's IPMI firmware is so old that it doesn't allow special characters in the user passwords. Despite Supermicro support pages saying that the max pw length is 20 characters, I wasn't able to use more than 16. There's also a handful of service ports that are enabled by default so check those out. This site has easy instructions to reset the admin pw for if (when) you lock yourself out: http://tcpip.me/2018/06/23/how-to-recover-forgotten-ipmi-credentials-on-pfsense/

No. You can "update" by backup'ing your configuration and installing 2.4.4 from USB/Image/ISO medium though. If you put that configuration either on the stick or installing over the current installation (and choose recover config in the installer) you should get a 2.4.4 installation with your current configuration. But WAN/internet access is required after installation to correctly re-install packages etc.

Thank you..