@Alena-Cantillo said in Pfsense is unreachable after reboot.: Have you find any solution about that? I mean when the pfsense doesn't reload Can't tell. Only the admin in front of the device can discover that. By using the console cable he would be able to see pfSense booting, and if there was an issue, it will be shown on the console screen.

@stephenw10 said in Reboot using R/r (Reroot): Does not restart pfBlockerNG (DNSBL, firewall filter) and others: So they do restart as expected? Yes, I should have include I have Airvpn configured and using all three available connections as a Gateway Group along with balancing, so it takes a moment or two to get going...

Just want to say I appreciate the replies. There is documentation from the vendor on URLs and IPs to whitelist so that’s a win. IPs and Ports

@stephenw10 Yes, that appeared to have fixed it. Thanks again for your prompt help.

Mmm, that's not an issue I'm aware of. Hard to see what might cause that. I assume you can make other changes to the config successfully still?

You would still see version updates available if a vulnerability was discovered that warranted a pfSense Plus release. Same as an other pfSense Plus install.

It will automatically be set to 1492. If you run ifconfig you can see what the ppp interface and it's parent are using for MTU. If your WAN/ISP supports it you may be able to set the parent NIC to 1508 in order to get the full 1500B across PPPoE. Steve

What's the existing load on the 1Gig connection at peak times ? If it's below 100%, then there's your required bandwidth. If it's often maxed out, then you need the 10G link before confirming PfSense hardware.

@stephenw10 Yes, I see the BGP session opening sates via IPv4 but not IPv6.

@SteveITS I ended up with another TAC license - but thanks anyway

@stephenw10 excellent. Solved my issue with missing packages. Up to this point I was getting: DBG(1)[97341]> pkg initialized Updating pfSense-core repository catalogue... DBG(1)[97341]> PkgRepo: verifying update for pfSense-core DBG(1)[97341]> PkgRepo: need forced update of pfSense-core DBG(1)[97341]> Pkgrepo, begin update of '/var/db/pkg/repo-pfSense-core.sqlite' DBG(1)[97341]> Request to fetch pkg+https://pkg.pfsense.org/pfSense_v2_7_2_amd64-core/meta.conf DBG(1)[97341]> curl_open DBG(1)[97341]> Fetch: fetcher used: pkg+https DBG(1)[97341]> curl> fetching https://pkg.pfsense.org/pfSense_v2_7_2_amd64-core/meta.conf DBG(1)[97341]> CURL> attempting to fetch from , left retry 3 * Couldn't find host pkg00-atx.netgate.com in the .netrc file; using defaults * Trying 208.123.73.207:443... * Connected to pkg00-atx.netgate.com (208.123.73.207) port 443 * ALPN: curl offers http/1.1 * CAfile: none * CApath: /etc/ssl/certs/ * SSL certificate problem: self-signed certificate in certificate chain * Closing connection DBG(1)[97341]> CURL> attempting to fetch from , left retry 2 After the rehash, this was fixed and the packages re-appeared in the GUI. Many thanks.

it seems to be stable on OpenVPN... no reboots/crash at the moment. The only setup difference with the IPSec configuration is that on IPSec I had to manually enter the default route (route -6 add default <tunnel endpoint>) because for some strange reason it was not set automatically (even if I selected the gateway as default in the routing menu). I'll write if it happens again, but I would say that the problem only seems to be present on IPSec.

Yup VLANs are treated like any other interface in pfSense. The firewall rules on the interfaces apply to all traffic entering them and are stateful by default. It's possible to create stateless rules there if you need to for some obscure reason but you have to try hard.

@Limrick08 not stupid by any means. Seeing root logins would peak my interest as well to understand what they are ;)

The internal NIC, mvneta1, sees traffic from the switch on port 5 exactly as if it was an external switch. So an interface assigned as mvneta1 directly (as LAN is by default) will see untagged traffic. You would create VLAN interfaces on mvneta1 and assign them to see the tagged traffic arriving on each VLAN. Since it's working I assume that's what you have done. Steve

@davidylau Sometimes the anti spam triggers, especially for accounts without upvotes.

@stephenw10 Thanks for testing and the support. I found the problem in the "unofficial" script. Somehow only using the ip-adress wasn't working anymore. Adding https to it fixed it. Sometimes the solution is simple but the error was misleading. This case is closed. Thanks again.

What exactly was it you tried to import and how?

Yup, test it first is good advice. https://docs.netgate.com/pfsense/en/latest/recipes/freebsd-pkg-repo.html#concerns-warnings

@stephenw10 Sorry about that, had /32 instead of /24 under aliases. My fault! Thanks for your help. All good now!