@johnpoz Yeah, I just checked that. Arp cache won't catch anything that's not in the subnet. I suppose tcpdump --immediate-mode might work to capture for a script.

@chpalmer said in Really Strange Behaviour - Have I been Hacked?: SIP clients are designed to keep the connection live. 24/7. Some devices are better designed than others. SIP was not originally designed to be behind NAT. NAT was hacked in (emphasis on hack) later when the idea of marketing to the residential and small business markets. Vonage was sued early on for patent infringement. Since then other carriers are being very careful to keep out of that particular court room and thus everyone does things just a little different. The problem becomes when you as a customer of one company with their specific devices has an issue trying to find someone that knows that exact system and their requirements/method of operation can be difficult. Generally things are close enough and the knowledge that is bestowed is usually enough. But little things can crop up and stimie everyone.. You don't want your ATA states to expire normally. The whole idea is that a constant connection is kept active between the ATA/phone device and the carrier SIP server. Otherwise you would not be happy with the quality of your VOIP carrier. Thanks for the reply @chpalmer - As a result of your email, I did a quick pcap to see what what going on (now that my system is functioning normally), and from what I can see the ATA sends a UDP packet about very 20-25s to keep the firewall open. And I agree with you that documentation of SIP is somewhat "spotty"... you may have uncovered the reason why. I don't know when that was or when the suit occurred, but IIUC a patent is good for 17 years, so it should hopefully be expiring soon as this is a very mature protocol.

I wrote on a similar thing here on the forum about 7 months ago, it was just a DOCSIS issue (DOCSIS modem + WAN dynamic IP) MAC spoofing was useful, because the CMTS and EdgeQAM in the ISP network, were manufactured by Cisco. pcEngines APU MAC vendor address CMTS doesn't seem to like it and at the moment we spoofed the MAC address of an old E900 Cisco router, the APU pfSense box immediately got the DHCP lease on WAN interface. (perhaps Cisco to Cisco) [image: 1591441140071-52ec5c9b-c26f-4e72-9226-b11efa2c55de-image.png] and [image: 1591441247927-e1744a86-91c1-4f5c-beb6-ad51fd3c138f-image.png]

Hi @q54e3w - at the outset it looks like some bufferbloat is developing, which may be a result of your line (cable node) being heavily utilized / congested. One thing I would recommend is trying traffic shaping with FQ-Codel to see if that will stabilize the connection: https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/815 Try setting this up and then experiment with the up and down limits until you have more stable latency under load (i.e. reduced to no bufferbloat). Hope this helps.

áhhhh, so I get it just what I found and only partially similar question https://forum.netgate.com/topic/57097/squid3-mutual-authentification-with-client-certificate/5 http://squid-web-proxy-cache.1019090.n4.nabble.com/icap-and-https-td3329449.html

@mogarchy THANK YOU! That was the trick. Clearly I don't understand how the rules is supposed to read.

And this client gets a dhcp address? Yeah with @JKnott here if you get duplex and speed with client, and then using the same wired connected to switch you do not.. Then something night right with that switch..

@bigbird007 said in Pfsense performance: wait for it to fail, see if I can work it out Finding the issue is actually easy with the FreeRadius package - process. First : stop the FreeRaduisx instance in the GUI, if it is running. Then, use the console or better SSH access, and enter god-mode : option 8. Type the magic command : radiusd -X A boatload of log line scroll over your screen. After an initial startup phase, thing will calm down on your screen. You can leave this screen open, and have break, day of, some sort of delay. When the process dies, one of the last lines will probably printed in red. That is your issue. The question was : what is the issue. The answer will be : read the red line.

@mykl With the Kingston UV500 series, I had no problem (for NGFW)

perfect You see, it's already clear what's wrong... You can do two things: you experiment, but it can cost useless money, if it doesn't work and you buy one this (the compatibility of the I350 is legendary): https://www.dell.com/en-au/work/shop/dell-intel-ethernet-i350-t-quad-port-1-gigabit-server-adapter-low-profile/apd/540-11333/networking or https://www.bargainhardware.co.uk/intel-i350-t4-quad-port-rj45-1gbps-low-profile-pcie-x4-nic -or you go that way, which I have already experienced and you use a Broadcom T4 NIC (bce4), I know for sure it works: https://www.bargainhardware.co.uk/broadcom-bcm5709-quad-port-rj45-1gbps-low-profile-pcie-x4-nic (we use it without any problems) I'm sure with such a strong CPU, the (bce4) driver has no disadvantages when running pfSense

@Harrye It really depends on what NIC you're using ... also, may I suggest to hide your Netgate ID as that's confidential info.

Will do, thanks!

Doesn't look like free is included, but you can try Diagnostics/System Activity.

Nearly all traffic is https these days. This implies that the 'router' - all routers - on the data path can not 'see' the traffic payload. pfSense can not snip out parts and bits. pfSense sees source and destination IP, ports, some packet flags, a packet size and number, and scrambled data. That's it. You could have added your own initial advice ; re install Windows ^^ Btw : routers can get hacked, of course. Not because the hacker wants to see what the users on the routers LAN(s) are doing. They have other interests.

@Gertjan said in Ethernet devices being assigned WI-Fi Range IP addresses - How do I keep the subnets separate?: Normally, when you are at home, and wired up (cable) you shut down ( there is a key on the keyboard for this ) the Wifi. I have never done that. I just rely on the metric. Also, with Linux, unlike Windows, the WiFi address is still reachable via the Ethernet port. So, if I ping the WiFi address, while connected with Ethernet, the ping goes in via Ethernet. I have verified that with Wireshark.

Oke I noted it

fix: https://redmine.pfsense.org/issues/10625