@mappe that would be a good test to validate your setting of the IP to static, answers when asked about that IP.

you could send the sniff to your ISP, and say look here - it answers a arp probe for the IP you gave me.

I'm going with hardware, we have an identical box in HA with this one as the failover and it hasn't had any issues.

Replacements are on the way. Thanks for the help.

@ajaxous said in 23.01 upgraded from 22.05 appears to be causing cable modem on WAN port to lock up:

Arris TM3402A

https://approvedmodemlist.com/intel-puma-6-modem-list-chipset-defects/

Try changing your WAN mac address to get a different IP to rule out someone sending the packets that can trigger this particular chipset to lockup.

@rcoleman-netgate Hi Ryan, thank for the reply.

i did end up fixing it, by mirroring repo files and cert files from my working node.

im back up and running now! but good to know that there is a way to clear the cert and start over, ill keep that in mind if i ever get stuck and just cant get going. thanks!

@daduls I rarely leave feedback and it just leads to bad feedback from the seller. No point.

@paulk201270 said in 23.01 crashing frequently. IPSEC connections constantly dropping and respawning. Unable to access http over VPN, address constantly times out.:

@jimp Many thanks. Looks like that is the root cause. Have set the tuneable and have not seen a subsequent reboot. Could this also be a cause of the listed error on the 6100 in the Bug database??

No, that's a completely different crash/backtrace.

@bfu Hello, I am having the same issue. Were you ever able to find a solution?

@johnpoz Thanks. I wasn't fully aware of the usefulness of alias before. Indeed, blocking RFC1918 is a more convenient way. I've reconfigured my firewall and it's running well.

Also thanks to @SteveITS

@lnguyen @stephenw10 that did the trick, thanks much for helping me out, it was GE25 on which pfsense upstream cable was in.

[Solution]

There were some outgoing port rules in the VMWare Esxi firewall (outgoing ports) that prevented traffic on ports 80 and 443.

I disabled these rules and updating Windows and Linux worked, as well as accessing the http sites.

Thanks.

@defunct78 Adding more details to my post.

tcpdump on the inside shows the ServFail as stated. Enabling TLS causes these errors. Again, DNSSEC has always been disabled.

13:48:47.739211 IP (tos 0x0, ttl 64, id 57751, offset 0, flags [none], proto UDP (17), length 59, bad cksum 0 (->dab3)!) 192.168.X.254.53 > 192.168.X.24.63104: [bad udp cksum 0xbe9f -> 0xb98a!] 11684 ServFail q: AAAA? i.ebayimg.com. 0/0/0 (31)

and IPv6

13:32:22.688367 IP6 (hlim 64, next-header UDP (17) payload length: 41) XXX:XXX:XXX:30::1.53 > XXX:XXX:XXX:30:f470:14f5:f634:1308.55800: [udp sum ok] 5238 ServFail q: AAAA? ssl.gstatic.com. 0/0/0 (33)

I am not seeing errors on the WAN side, though that data is encrypted so it is a bit harder to see the content. I have tried Quad9 and Cloudflare both. Also disabled IPv6 on the client side just to isolate the issue, none of these seemed to have changed the behavior.

@mrewers I had a similar problem with one of mine. Put in a ticket; tech support had me send it in. They pulled it apart and verified everything, reinstalled the software and I'm not sure what else and returned it. Zero problems after that.

I suggest you contact them.

@steveits These are APU2 units. Probably 3 years old. I know a restore just puts the xml back into place but this happened on 2 units back to back. I find it hard to believe both drives crapped out together, you know? Something must have happened but I've no clue. Now I'm trying to figure out what was affected so I can determine what was done. So far I've created a bootable USB and can get into the recovery on it.

In df I can see listings for /zroot/var, zroot/tmp, zroot, and zroot/ROOT/default. Each of them show Size=106G and Avail=106G. They are essentially all mounted under /tmp/mnt_recovery in different folders. If I navigate to /tmp/mnt_recovery and run the entire folder is only 1.8M in size. It seems like the whole drive was wiped and I'm trying to determine how this was done. All they are telling me is they went into the Backup&Restore, selected the xml, and clicked Restore. If they did something other than that and managed to wipe the drive I need to know how they did it so I can stop it from happening again. I'm lucky this is done on units being pulled and not on production units.

@netgate1100guy See https://forum.netgate.com/topic/178049/pfsense-plus-23-01-updates-on-the-1100-and-2100-systems/. The repos for 22.05 are turned off for those models due to a serious problem updating older devices. Once they are happy with the revised update script and enable it again, you can upgrade (or set the update branch to previous/22.05 and stay there), or if you don't want to wait you can manually install 23.01 and go from there. I think the update looks more complicated than it is...it just copies the image to the 1100's drive.

@mauro-tridici while you could setup a proxy on pfsense with haproxy, I really wouldn't go that route. If you want remote users to look like they come from your corp network. I would vpn them into your network, and route whatever traffic you want to come from a corp IP to something out the internet through the vpn.

@elmo1943
Go to the IP tab and configure your inbound and outbound interfaces.