@stephenw10 For the record, the network is today working 100% magically. I might buy a 3 NIC PCIe card to resolve any potential IP conflicts. Just a guess as the tcpdump was a bit detailed.

@JonathanLee said in Log / routing full of upnp related messages: Yes does your ip schema still the same Hmm? Does my IP schema still ?look? the same?? The LAN, where UPnP is enabled has two of the Static IP's (gaming PCs) which in the ACL list (192.168.1.92) and they have the same port range allowed. The IP's that show up in the log are all from the DHCP range .130 and above.

Yes we are running current now in Plus so you would need to use 15. And, yes, I can ask but I think there would be almost no chance of Netgate developers getting involved here.

@johnpoz , Thankx....

The WAN interface is the local NIC in pfSense. It has an IP address assigned to it. The gateway is the remote device that pfSense sends traffic to which also has an IP address assigned to it. The WAN and gateway IP addresses are (almost always) in the same subnet so they can connect at layer 2. I.E. using ARP or DHCP.

Remember Parallel DB25 print servers where you could connect your laser printer to a couple years ago? Same thing if it has no web server running or access to the network it won't work. My question is can you do a test page from the printer itself? Think in Isolate. Does the printer work? Does it get an IP address? If that works why can't windows see it. Can you ping it? Can you ping pong it from the firewall? Have you attempted a complete wireless reset on it? Can it see the SSID.

This is a new install? Behind an ISP router? What IPs are you actually seeing now? How is the WAN configured? What is not working? Steve

Your 'Allow Trusted Devices' rule is UDP only. If that is intended to pass traffic it should be UDP+TCP or TCP only at least.

@Efren Sorry, it's already fixed. There was another AP on the network that had DHCP activated giving those IPs.

@stephenw10 Awesome. Will give it a go this evening. Hope that solves the problem.

@johnpoz Yea I just read that post, I had it setup as a /31 as there was only going to be one host on it, but I could not set that host as static so tried to add the DHCP server, Increased to a /30 and this seems to do the trick! I knew it had to be something stupid. Thanks!

@Bob-Dig - No, only one IPv6 Gateway on WAN

@GPz1100 Yes, it's not really an issue but my OCD.

@stephenw10 I get by with a little help from my friends! Thanks again

@antonioremigio1 Hope gave them a bit of business end about - thought you said our IP wasn't blocked ;)

A lot of backend changes forced a longer development period. We are targeting October but that is dependent on new bugs found etc. See the September newsletter. Steve

Yeah, I'm probably out of date. Again!

Hmm, well that shouldn't happen! You have to run the command several times in parallel? Or you ran it, quit, reran it etc? That fills the state table very quickly for me with one process but doesn't crash it. I simply see logged: Oct 1 21:14:47 kernel TCP syncache overflow detected; using syncookies for the next 15 seconds Oct 1 21:16:01 kernel [zone: pf states] PF states limit reached The firewall stops responding during the flood and the gateway throws some errors because the pings fail. That's a smaller device also running 2.7.2. Steve

Well I'm not sure why it would ever release that. SWAP would only need to be cleared if it got close to exhaustion. There are some tunable values but I'm not sure any of them would release used swap. https://man.freebsd.org/cgi/man.cgi?query=tuning#SYSCTL_TUNING

@michmoor depending on your environment and traffic flows you could adjust those.. but its much less resources to just leave a state open then create a new one.. But depending on how many clients, what sort of traffic patterns, how many different connections they make.. You could run into a scenario where 24 hours might be too long and you run into state exhaustion. If that was the case you could adjust the default timeouts to try and mitigate such issues. edit: that being said normally when client is done with a conversation it would close the session with fin, fin,ack or even a RST.. Odd that its still open, but if the device is off and was removed from the network before it could close the session then yeah could stay open for 24 hours. Unless the other end closed it.