@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.

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)

52ec5c9b-c26f-4e72-9226-b11efa2c55de-image.png

and ☺

e1744a86-91c1-4f5c-beb6-ad51fd3c138f-image.png