I've resolved this using: https://github.com/jaredhendrickson13/pfsense-automator

@Alanesi There is a method where the header is examined for the original URL and the connection forwarded based on that. However, I have no experience with that and it would require something beyond the basic pfSense.

You probably don't need to go higher than 1M IMO. Currently, at least. Larger tables will cause more effect from 10414 if you're hitting that too. Until 2.4.5p1 is released. Steve

Look at the output of netstat -LaAn and see what port number that pcb corresponds to, and then look at sockstat and see what is listening on that port. That one process is being overloaded with requests, whatever it may be.

The two pfSense boxes can ping ALL of each others' interfaces. But the hosts within each respective Subnet can not be pinged. I think I may have taken a step back in terms of making things work. Here is a new more accurate diagram with some pfsense parameters attached. [image: 1591643514763-untitled.jpg]

John, will scope those variables out, thanks.

Could be any number of things. What error do you see? https://docs.netgate.com/pfsense/en/latest/routing/unable-to-access-some-websites.html Steve

Yes, you are right, and this is a little bit complicated situation. Our users complain that they can access sites with "wrong" web server setup directly, but behind squid proxy. And there are many sites (including goverment related), which are still wrong, but needed to be accessed.. on the other hand, nobody can force site admins to update to proper config. Here comes in OpenSSL 1.1.1, which is able to handle this situation. And yes, I do not want to allow accept expired certs in squid. I assume that squid uses pfsense's cert store, but I could not find exact documentation.

@Cornelp said in rc.update_bogons.sh: Anyone knows what this could be? Or where its coming from? These was (still is ?) a cert issue with the root certificate of .netgate.com 5also pfsense.org ?) - the root certificate is used / maintained by the certificate authority. Check out the first 30 or lines when executing manually: curl -v https://files.pfsense.org/lists/fullbogons-ipv4.txt You should find : .. * subject: OU=Domain Control Validated; OU=PositiveSSL Wildcard; CN=*.pfsense.org * start date: Aug 10 00:00:00 2018 GMT * expire date: Aug 21 23:59:59 2020 GMT * subjectAltName: host "files.pfsense.org" matched cert's "*.pfsense.org" * issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA * SSL certificate verify ok. ...

Thanks for the answer! After i got the REAL hw that my pfsense will run on, it suddenly worked without promiscous mode, it has 4xIntel NICs, so om guessing the problem i had with the other hw was maybe bad realtek/marvel drivers? Thought it might be usefull info for someone els with the same problem

Yup. This now seems to be the best source: https://github.com/MonkWho/pfatt

@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