@stephenw10 said in Route pfsense itself over VPN.:

Hmm, well it sure seems like it's set to serial as primary console from what you're seeing. But as I say you should be able to see which is set at the vga console.

Success !!!

I made the mistake when creating a static route by typing ip address of openvpn server and then selecting the subnet. Selecting the subnet was a mistake that caused pfsense to be stuck at boot. I created new static route by typing the openvpn server address, chose the appropriate WAN and saved the setting. After reboot, pfsense booted just fine. I created additional static routes for the remaining vpn clients and everything just worked. Rebooted once again, no issues. Then i selected openvpn client as a default gateway and that was it.

All tailscale clients are now going through vpn, and all vpn clients connect without any issues after reboot.

Thank you very much Stephen. All this would not be possible without your help. Im marking this thread as resolved.

Cheers.

Nice! That does imply some ARP issue. You shouldn't really have to do that. But if you do keep that in place you should add it as a system Tunable:

https://docs.netgate.com/pfsense/en/latest/config/advanced-tunables.html

@mvikman oh sorry - I must of hit reply on wrong post, corrected ;) thanks

Good idea about redmine, I will look to see if anything in there already - and not make the suggestion

Supplement, for future reference if someone encounters the same problem.

I did some tests later and ruled out pf, but the problem was the same.
The final result was that the esxi virtual machine would check the mac match by default. If it does not match the mac in the vmx configuration file, the communication will fail. Customizing the mac on the gui can only set a fixed prefix,

Reference:

https://community.broadcom.com/vmware-cloud-foundation/discussion/custom-mac-address-in-esx-4#bm65eebd63-587b-41e1-8108-b951b7ef03d0

And because the new version of esxi parameter definition checkMACAddress is invalid

ethernet1.checkMACAddress = "false"

I don't want to enable promiscuous mode in the vds port group, so the final solution is to add a network card to modify the vmx configuration of the virtual machine to define two items:

ethernet1.addressType = "static" ethernet1.address = "10:2d:3c:40:55:63"

Reference:

https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-F9243FED-F081-498F-B4A9-EF950292AF77.html

Of course, modify mac from the system layer,
1, such as pfsense, modify /etc/inc/interfaces.inc Add mwexec ("/sbin/ifconfig vmx0 ether 10:2d:3c:40:55:63"); Updates will be overwritten
2, Windows system settings network card mac
and then enable the three items (Promiscuous Mode, MAC Address Changes, Forged Transmits) on vds. It is feasible and communication is possible. I did not adopt this solution

@VioletDragon said in pfSense Auto Backup:

Do you know if this will backup configs for like pfBlockerng, Snort etc?

You've missed somehow what pfSense is.
Ok, its a firewall router. Like many out there, With tonnes of extras.
The main difference with other firewalls is that is is for 99,9 % Web interface driven, and it has just one (1) config file. This file contains everything.

Just read it : export it and open it in a text editor. You'll get the picture quickly.

No worries, glad you were able to get back up and running. 👍

@CatSpecial202 there is another thread going over this topic actually..

587 is explicit use of tls, ie it would make a non secure connection and then use starttls to to convert to an encrypted session. While port 465 is implicit connection only, so no that checkbox would prob not work on port 587

here is the thread where that is being discussed, kind of as a side topic

https://forum.netgate.com/topic/190885/empty-message-id-in-smtp-test-email

@stephenw10

Thank you so much

@Gertjan Thank you, This helps!

Yup, check for watchdog errors from the realtek driver. If you see any you definitely need the alternative driver.

For reference when coming from 2.7.0 you almost always need to run certctl rehash in order to see the update. That's fixed in 2.7.1 but it appears you may not actually have been on that.

Apologies for my late reply!

The IP does change from time to time, but usually over a long period (a few months). I've received such notices from the ISP for many months too, though I'm not sure if it was the same or not when they first started emailing me.

That said, I never thought someone else having the IP before could have caused it. It's the only plausible explanation that I've come across and could well explain it.

I did think to contact my ISP, but they're totally useless at the best of times. Will be switching to another provider within a couple of weeks, so will see if it continues after that.

Also, just a thank you to everyone who offered help 🙂

No, it is because my streamer is not from an official Spotify Connect authorized vendor. Instead, they use the open-source Librespot client library, which can be flakey depending on its implementation.

@johnpoz I will report and check out logs...also on my Mac, for now, interface acts stable... I dont do on my Mac Torrents downloading or magnet or stuff in the DarkWeb...mostly using just email and webservices and online tv on my Mac. But who knows, I often see in pfblocker up to 500 attacks per hour...on WAN Interface, my Gateway is Mullvad VPN over WireGuard, which nearly never gets attacked. But sure, that hasnt do to with my Mac Interface went down and up randomly, Thank you 😊

@johnpoz Sounds complicated, I'm very new to pfsense so a lot of my work on it have been guided by videos and how to guides, I have not longed started with pfsense and I am still getting used to it.

@Rookiesense Well in that case you have no option but to keep the ISP modem.
But you should look for an option called "bridge mode" (or perhaps "pass thru" mode). In that mode, you should get a different IP on pfsense WAN. The same you would see if you go to whatsmyip.com = your public IP.

If not, you have to live with a double NAT situation, but then the DMZ is your best bet.
In the ISP modem, make sure you give pfsense a static IP, does not matter which. Then in the DMZ setting, you enter that IP. This way all ports are open towards pfsense.

Then you turn the wireless router into an access point and connect one of it's LAN ports to the pfsense LAN (your home network). All you have to do to make it into an AP is typically just log in and turn off DHCP. Important not to use the WAN port on this router.

So connections go:
ISP Modem -> pfsense -> any swithe(s) -> Wireless AP (router)

Yeah it should never reach that size. It's probably unable to rotate them because of the compression time taking longer than the rotation time.

I would clear the log files and disable compression. Or increase the log size and reduce the amount logging so they aren't rotating as often.

Check the system logs at the time it starts. But otherwise, yes, try to check it while it happening.

@tomashk Thanks for this, on my pfsense 2.7.2 I used this commands

on CLI
zfs set sync=disabled pfSense
System -> Advanced -> System Tunables - set vfs.zfs.txg.timeout to 180

dropped from 28% IO delay to 5 %
26dfeae6-4122-40bc-a1d3-2ad978396090-image.png