@DaddyGo ISP router with IKEv2 passthrough (NAT1) + pfSense IKEv2 passthrough(?) (NAT2) + Win10 with VPN client SW) Yes the above is the current setup. As is apparent, I don't know enough about this, but I was trying to apply the same principle to my separate, unrelated internal OpenVPN server. Where I had to passthrough ports on the ISP router for it to work. Win10 (work administered) is using Win10's built-in IKEv2 VPN. I read pfsense cannot be set-up as a IKEv2 client with username /password authentication?

What is your pfsense build running on? Is it virtualised by any chance? It may not be the same issue as mine, but I had EXACTLY the same symptoms you are seeing with Virgin Media and their 'super hub' - turned out that it was the Virtual NIC driver which was causing the issues. I wasn't using the latest VMNX3 driver on this specific VM, so I changed that and just like magic all those issues disappeared. As i say, it may be totally unrelated to you but I thought I'd share in case it helped.

I haven't received any E-mails today so lets hope so

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.