@jknott that i don't know.

I arrived at 1472 by plugging my win10 laptop directly into the modem and pinging with the flag set at whatever it was and working my way down until it stopped fragmenting. i didn't realize that the 28bits for the header were to be added onto the mtu size once the fragmentation limit was found. it's all fine, works great without any issue. just thought you'd all like to know about my experience.

It seems to be working. Thanks

@sfigueroa

If you're setting up a client, such as a notebook computer, you just have to use the client export. If you're setting up pfSense on a remote LAN, then you use the client settings.

@fbgluck A network that connects 2 routers would be a transit network. So what IP range to be used would be up to who manages the overall network.

if the downstream network is managed by someone else, and there is no overall person that has access to the complete network, then the owners/admins of the upstream network/router should provide you with the transit IPs to be used. This could be something as small as a /30 or if there might be other routers on the same transit maybe a /29 or /28 even..

But I am kind of with @Jarhead here, maybe it came off the wrong way.. But this does seem like a basic networking 101 sort off question..

As to

1&2) this would be something that does not overlap with the network(s) on the other side of the edge router in your drawing or on the lan side of pfsense. So something other than 10.9/16 or 192.168.0/24, common to use say 172.16/12 rfc1918 block if you are using 10 and 192.168 networks. So an example of this transit network might be 172.16.0.0/30 the upstream is normally the lower IP in the range.. So the edge router would be say .1 and the pfsense wan would be .2 That the upstream be the lower IP is not a written in stone sort of rule, it could be the last IP in the range. But normally its the first IP in the range used for the transit. Also use of small networks for transit is not a rule or anything either, it could be a /24 for example.. You would just want to make sure that the transit networks you use in your network do not overlap with other networks that are routed.

this is pretty clear, on your drawing you show 192.168.0.252, this would be the gateway of devices on the 192.168.0/24 network then.

edit: To your last comment, yeah pfsense doesn't have to nat for sure. Nat would only have to be done upstream in the network where the rfc1918 space might need to get to a public range, etc. Even if you natted at pfsense, you would still need an upstream nat if these devices on your classroom network have need to get off the school network and go to say the internet, etc

@stephenw10 Thank you for your help. Then I realized that the whitelist had not been configured.

@nollipfsense I was kinda coming to that idea.

Thanks....

@starsandbars There is a long thread here if you hadn’t found it yet:
https://forum.netgate.com/topic/161424/dhcp-lease-screen-not-loading/

@stephenw10 hmm something like that in a way

For example here

Essentially, i think the feature/logic needs to be built into OpenVPN and not a pfsense thing specifically.

@johnpoz said in not of my client can resolve it's own hostname:

local.lan for longest time, in the middle of moving over to home.arpa - just waiting for my certs to expire and do it natur

Thanks for the suggestion. I plan on moving in several months and I'll take the opportunity to update.

@rcalhoun If your store has any devices that use Bluetooth, they might record the Bluetooth MAC addresses of the burglars' phones, if they had them (likely) and had Bluetooth enabled (almost certainly).

@stephenw10 Did that. Issues:

https://forum.netgate.com/topic/177753/new-6100-high-tem-on-dev-cordbuc-0-temperature

https://forum.netgate.com/topic/177755/6100-slow-in-comparison-to-protectli-fw6e/2

@michmoor said in Assign a second IP to a LAN:

Why keep the old IP as an Alias unless theres that one client that cant be moved to the new IP range for some reason.

Agree - the only reason for the old IP address as a vip, is if there is going to be something on the network that you can not get to for a bit, and you need to run in a mode where the new and the old IP ranges have to run at same time..

But if you have a change window, and can move all the servers to the new IP range - there would be no need for a vip.. Unless you were trying to make the changes remote and needed to be able to get to devices from another network to change them. If your local or on the same network then no reason..

@adrien-1 Each modification of what?

Do you have a large rule set? There is this patch available in the System Patches package:

Disable pf counter data preservation to temporarily work around latency when reloading large rulesets (Redmine #12827)

@stephenw10 Oh i understand now, ill take a look and let you know how it goes! thank you so much!

@stephenw10

Yeah 100%, which is why I thought it might have been a driver thing in FreeBSD. zero issues in linux and also using a netgear router with a 2.5g port. Though I think the netgear stuff might be linux based so that would explain it and no issues in windows either, but prior to this they weren't running in 2.5g

We've tried to catch most things and fix them already, but there may be some more rare/lingering issues that we haven't been able to replicate here.

When in doubt, look at the open issues for packages and see if there are any recent ones for packages you are interested in.

I've read this message 3 or 4 times now, and I can't understand most of it. Probably english isn't your native language, but then ask someone to assist you in at least writing your issue down so others can actually decipher it. Or create a network diagram / overview and post it here.

If it's about speed, run iPerf with -P4 for parrallel mode. A single thread will not reach 10Gbps on regular X64 hardware, as no offloading is present. A dedicated ASIC like in a switch or 'real' router, can do it during breakfast. But a general purpose X86/64 CPU can't, and will usually be limited between 2 and 3.5Gbps, 4Gbps if you have some good single thread performance.

We run pfSense 2.6 CE on pretty beefy Xeon 6248R CPU's and another pair on Xeon 5118 CPU's. The 6248R does about 3.5-4 Gbps, the more common 5118 between 2.5 and 3.5. That is single connection though. If I do multiple connections I easiliy saturate bandwidth.

Hmm, this is exactly the sort of thing that might cause the VLAN config change to fail. I wonder if you're seeing interfaces use the non-primary IP...
https://redmine.pfsense.org/issues/11545

@elrick75 said in PHP Errors on csrf-magic.php and diag_command.php files:

(tried to allocate 4096 bytes) in /usr/local/www/diag_command.php

It looks like something was run in the Diag > Command Prompt page that didn't have a limited runtime and ended up exhausting the PHP memory limit.
Only ever run things there that complete immediately. So never run something like ping 8.8.8.8 there because it will just run continually in the background . If you need to set a count limit so it returns after that like ping -c 3 8.8.8.8.

Steve