i found in the end it was just too confusing for me......

Ha. Classic!

@stephenw10 said in pfSense 2.4 wont reboot after interface removal - route cannot be added, network unreachable: Do those tunnels come up correctly after bootup is complete? If so that might just have to be considered log spam if those fqdns actually need to be resolved. Otherwise you could just use IPs there or maybe add static entries for them. The endpoints are on dynamic IPs, hence the need for hostnames. They resolve to dynamic ones. The tunnels come up, I would consider it log spam.

well i can't set MTU to 9000. raspberry does not support MTU greater than 1500, and i have one with kodi that i use with my NAS and one configured as ntp server

@stephenw10 Managed to solve it myself. I don't know how I missed this before when I created the VLAN's I created them on igb2 rather than igb1 which is where my LAN network resides. I changed that and now everything is working fine as it was before I started a fresh configuration. Thank you for the suggestions anyway!

@zyntec724 said in Can't connect to steam network through steam client: pf box Could be simply because your Download server is set to a different location and basically it's proving so hard for steam to pull out the files from the remote server. Go to the setting and change the Download Location or Server to your nearest location. I hope this helps. To resolve this you must check this https://validedge.com/could-not-connect-steam-network/ and if you got the solution.

192.168.xxx.0/24 xxx took some research to find one that was not on Google as a default that some company uses or has ever used. Ah I see what you mean now. That's obviously fine. It's very hard to judge peoples level of experience based only on a few forum posts. Which can easily lead to either coming across incredibly patronising or totally incomprehensible. I've done both! I had visions that you might be just using some random public subnet based on a Google search. Glad to see you're not. Steve

@stephenw10 [image: 1567792260577-315aa528-656f-4437-8b6e-ba71867c2784-image.png]

Disable any hardware off loading you might have. Check for other errors on that interface. Maybe a bad cable or failing NIC etc. Steve

Even on an older version it should not just restart for no reason. If there is nothing logged there to indicate a reason you should open a ticket with us here: https://go.netgate.com Steve

@Gertjan said in Sending logs over Telegram: When you SSH into pfSense you are root (admin). Funnily enough, I actually have a regular user account I use for creating my own hodge-podge VPN, which is restricted to port forwarding only. (I use sshuttle, which requires Python, and since pfSense doesn't have Python, I port forward to my NAS and then use sshuttle against the NAS) As for the removal of clog, thanks for the heads up.

Hmm, I guess it retained some config then. We have seen NICs that require a complete power cycle to clear some issues. Steve

I am running 2.4.4-RELEASE-p3 (amd64) the throughout updates the issue initially mentioned is still occurring. about once or twice a year i get a new WAN IP from my provider and my VOIP service no longer works, and within the states it still has the old WAN IP. i have to manually kill the states for it to refresh and work. i also have Under System / Advanced / Networking i have checked Reset All States where it says "Reset all states if WAN IP Address changes This option resets all states when a WAN IP Address changes instead of only states associated with the previous IP Address" even with above checked, the same issue mentioned initially in my post is still occurring. is this still a known issue?

It is crashing in the pfSync code so it's to see how that could happen unless something is using it. The pfsync interface does get created on all installs but I'm not aware of ever seeing an issue like that previously without it actually syncing. Steve

@jdeloach I don't, but that is the server they run all of their tests to for some reason.

Yeah, there is some difference between what happens when you run, say, rpcinfo from pfSense directly and when it's run from Proxmox. So I would run a pcap on the OpenVPN interface and compare them. rpcinfo will create quite a lot of output so you might want to use something simpler like just telneting to a port assuming that also fails from Proxmox. Steve

Good catch @JohanÅ ! Yea, I agree with Steve on this. The combination of large pfblocker lists and the register DHCP leases option in unbound has high potential for trouble. I had to disable DHCP registration in resolver also. Let us know how it goes.

Open a feature request at https://redmine.pfsense.org I have no idea how easy that might be though. Steve

Yes, you will need to define what you mean by 'seeing' here. And, yes, also where are you expecting to 'see' it from? If you can still open connections to it by IP address directly then pfSense is not blocking traffic. Steve

Hello, at least I have something to modify if users complain tomorrow hehe Thank you!