Yes, it looks like you might need the DHCP Relay package but I have no experience with that so I'll bow out at this point. Why are the clients on a different network than the servers?

So your going to run say https://www.paessler.com/prtg? Which is really the only one I know off the top of my head what would be windows.

If you do not allow port forwarding - how exactly would you access anything? Or even allow for snmp query over the internet?

I don't think you can. IIRC, squid's behaviour is to use the default gateway.

No it doesn't..The controller needs to run if you want to use specific features, like guest network, captive portal.. To be honest unless you want the info, you don't need the controller running.

And to be honest you can prob run guest policies without the captive portal - just look into the selfrun mode for details
https://help.ubnt.com/hc/en-us/articles/205222660-UniFi-Configuring-the-SELFRUN-State

1:1 NAT is not providing the outbound mail to the .160 IP address, it remains as .164

Packet Capture is not providing anything remotely useful to ascertain the issue either :(

https://doc.pfsense.org/index.php/Why_can't_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks

Use split DNS.

Changed the new devices to use commands so I can isolate to just the new systems (assuming you assign static IPs to all devices and your DHCP range is 100 - 199.

New Devices - date -v-1d '+%b %-d' | grep -f /dev/stdin /var/log/dhcpd.log | grep -E "([0-9]{1,3}[.]){3}[1-9]{3}" | grep "DHCPOFFER"

can't limit the upload. only working is download.

found the tutorial here https://forum.netgate.com/topic/107276/howto-multi-wan-traffic-shaper-with-bandwidth-limits-per-interface

Untitled111.jpg

Almost always enabling squid logging without enabling rotation.

I just found out it must have something to do with VLANs.

My setup:
4core 2ghz / 4gb / 4x I211-AT NIC
2x WAN (1x 250MBit / 1x GBit)
2x LAN
2x Netgear GS724T switches

Case1; with vlans (issues)
-> Server1 connected to LAN1 (no vlan)
-> Server2 connected to LAN2 (with tagged vlan behind the 2 Netgear switches)

Doing iperf3 between the two servers is bringing down the WAN1 interface! )(strange bacause there should be no traffic going over that interface) Doing iperf3 from server2 over WAN2 to another iperf3 server brings down WAN1 (note; traffic is going over WAN2, but WAN1 latency spikes and gateway goes down)
Latency spikes above 1000ms and then brings down the WAN.

Case2; no vlans (no issues)
-> Server1 connected to LAN1 (no vlan)
-> Server2 connected to LAN2 (NO VLAN behind the 2 Netgear switches)

Doing iperf3 between the two servers is giving me GBit. Doing iperf3 from server2 over WAN2 is giving me GBit WAN.
Latency doesn't spike above 10ms.

So, my conclusion is that the VLANs are causing a lot of problems with high throughput. I couldn't find many tweaks to do with VLANs in pfSense, so I hope someone has an idea about this? Thanks!

EDIT: It's not WAN2 that goes down in Case1 but WAN1. So, it's always WAN1 that's going down. Is there something about the default gateway that's used with all VLANs or something?

Search for "policy routing" instead of "selective routing" and you will probably get more pertinent search results.

@Grimson i have been blacklisted several times over the past week and cant seem to find which device is spamming from the network,although ran Malwarebytes basically on all client devices

I agree, makes no sense to define point to point rules (first 5) and then throw /24 behind it so the whole network can talk to each other. Also those rules are TCP only so if you are that specific, why not also include the ports instead of "all"?

I'd also sort the kind of infrastructure rules on top (allow DNS, Ping, NTP and 80/443 for updates or such likes) and make them more specific so it won't interfere with other rules. Normally if that's your DMZ I see no reason why my DMZ hosts should talk to any DNS out there if I have a resolver/forwarder with caching running myself. Same for NTP.

I would consider creating a RFC1918 Alias with all private IP space and use that instead of LAN net as a target so to reject all traffic from DMZ to other internal networks. If you specifically need a single IP or subnet, add that with a pass above the reject. So you can't accidentally introduce a new subnet on your firewall and open it up to network segments that it shouldn't be visible.

That are the basic thing's I'd consider.