Hi I wanted to ask about where to look at further. The workaround works and since then I have (for sole fun) tried to reproduce this on a fresh system with a main and a secondary virtual IP but have not been able to reproduce it. It has been reproducible though on this particular setup that has been update from 2.0.3 via 2.3.5 to latest 2.4.4-p1.

@johnpoz said in 2 Newbie Questions on Network Architecture: So when you do vlan X to Y on the same physical interface you have actually cut your bandwidth in half when devices on these different vlans are talking to each other. It's not quite that simple. While both VLANs are on the same wire, the portion of bandwidth will depend on the traffic patterns. For example, with a large file transfer, most of the bandwidth will be used in one direction, with only a small amount in the other. Bear in mind, with full duplex, what happens in one direction does not affect the other, so when doing that file transfer, one VLAN will have most of it's traffic in one direction and the other VLAN, in the other direction.

Filebeat now can take syslog udp input and transport over tcp tls. Use this install script i have made and just set pfsense to syslog to 127.0.0.1:9000 https://github.com/Noebas/pfsense-filebeat I can confirm filebeat is not compatible with clog, but running trough syslog works fine for me. Also the config includes snort and pfblockerng logging

@stephenw10 Happy new year! Yes, the risks are negligeable. I won't lose a penny if the network fails and I can easily make it up and running. I don't expect it to fail often nor fail for a long time thanks to the USB failover, back up, hardware failover (cold backup with exact same laptop and same configuration), etc. In any case, I just easily can shut down my PFsense router or DHCP server and switch the VLANs to switch the DHCP server to the WAN1 or WAN2. It isn't difficult. Furthermore, my family all has 4G and can use it as hotspot... Android smartphones, moreover, switch to 4g automatically when the connection isn't stable. Thus that is not at all big deal. Thanks,

I have redone all the setup configuration. This time, finally, I was able to reconnect to my VPN provider after a reboot. Let's hope it stays that way. I consider this thread to be solved. I appreciate all the inputs you guys have given me. I opened another ticket here asking for help about redirecting DNS queries.

Mmm, I thought that. Seems like it should still be one layer 2... But I'm seeing multiple references showing the opposite. As I'm reading it's setting static ARP that prevents them working correctly, hence mostly they just work. I guess more research needed... Steve

@marvosa the problem with using a SRV record is the client trying to use whatever service must use or ask for the SRV record or know to ask for it. Web browsers for example do not do this because of an old RFC.

@stephenw10 yep I was finally able to get it after interrupting the boot on both the install and initial boot.

Be aware that using ZFS in a virtual environment may have some unexpected behavior. ZFS is copy-on-write so it doesn't play well with thin provisioned storage, eventually it will take up the entire space allocated to its disk(s).

Still not sure. I'll be bringing the new switch online later this week.

Yet it didn't work at the default 1492. Interesting. Steve

You really don't want your firewall to be a host for syslog of other devices. Spin up a VM and use something else as your remote syslog.

I understand that, but lets put things in perspective, these are a few modules already part of the OS, the work to activate them is adding them to a build script, and the size of the modules? Average 14kB each. I have seen far bigger things taking much more effort implemented in pfSense. For reference modules are not loaded by default, they optional, so the risk of crashing on boot, simply by compiling them and distributing them is pretty much zero. If the end user has gone to the trouble of adding a module to their loader.conf.local then they can go to the trouble of removing it as well if it becomes a problem.

RTFM https://www.netgate.com/docs/pfsense/book/services/ntpd.html https://www.netgate.com/docs/pfsense/book/services/ntpd-gps.html

You keep your config.. You just want to make sure you have a backup in case the worse case scenario happens and you have to clean install. 99 out 100 you will be fine with just clicking go... But if its really production you have to make sure if the worst happens the down time is minimal.. Or you get yelled at, worse case could be a PSGE (pink slip generating event).. Any typical enterprise change control process would include backout plan, and recovery. I have had to fly out to locations for "risky" upgrades of hardware.. And then doing the work at after hours so that you have enough time to even get new hardware onside in the 4 hour support window and back up before production starts again, etc. The level of precautions needed to be taken depend on the level of production your talking about taking a risk with.. I click update on stuff all the time when there is no SLA for the service ;) I would say 999 out 1000 just hitting clickity clickity on the update will be fine.. But always plan for the worse ;) Let us know how it goes..

time up will also be in the stats time.up=81609.360209 Which would be in seconds. And to be honest most everything on my network points to downstream pihole, so that reduces the number of queries unbound sees because pihole only asks unbound for stuff that has not been blocked, and also it caches.. So if say 3 things asked for xyz.com unbound would only see the 1 from pihole, then piehole would serve the answer up to the clients via its cache.

That looks like the expected result. The gateway IP is whatever is upstream from you at the ISP. The interface IP is your local address that external sites see to reply to. Steve

In the end i managed to figure it out. It seems that the certificate is case sensitive so once i fixed that it all works. the only thing im not sure about is why it worked sometimes before i fixed it. thank you for your help

That... uuuuuhhh... would actually make a lot of sense. I'll go ahead and ask them, thanks!