@rtw915 said in WAN optimization/acceleration:

Now the SQL team needs me to find a way to improve SQL linked server transfer rates to synchronize transactions.

This will bring you back to the initial wan accelerator solution.
The only other possible solution is to redesing the db subsystem, utilizing some way of sql replication, taking into consideration propagation delays

@craigerr1 is P2P? Mobile?
Have u open the rules in both sides to allow traffic on your firewalls->rules->ipsec?
Regards!!!

Hello,

Kind reminder :)

https://forum.netgate.com/topic/163221/constraint-check-failed-rule_crl_validation-is-stale-but-requires-at-least-good/3

Same issue as this one, which had no responses.

@lst_hoe

@bp81 I believe we have found the resolution, and I wanted to post it here for anyone else encountering the issue.

In our DNS forwarder, we had a domain override set for our company's domain. This is the same domain in the hostname for the remote gateway listed above. The domain override was pointing at a DNS server that is not accessible without the tunnel up. Clearly this was causing the IPSec service to fail repeatedly to establish its tunnel.

So there was a misconfiguration on our part which we have fixed. I still maintain that it's a bug if the ipsec service causes the web gui to crash / become unresponsive even when it's a self induced failure state due to misconfiguration. I understand it's possible this may be a limitation of the ipsec service, but it is worth looking at even if it is an edge case.

The only thing that could present a difference here is the hardware crypto in the safexcel driver. But you said you tried using a cipher that does not effect (blowfish) so it can't be that directly.

So I'm left trying to think of something you might have had set in the old device that's somehow incompatible with the SG-1100. I can't see what that could be though.

The fact setting the tunnel to use ports 600/4600 allowed it to come up implies something in the path blocking the standard ports. The crypto hardware doesn't care what ports are in use for example.

It really 'feels' like the upstream device trying to do something clever with IPSec traffic.

Are we able to review the config you are importing to the 1100? If you open a ticket with us and reference this thread the guys will make sure I see it.

It's hard to see how this could be a hardware issue. If we swapped it out I would expect another device to do exactly the same thing given the same config.

Steve

@djohnson
This is a late reply but it may assist someone else in future.
The VOIP audio traffic (RTP) require separate UDP ports to be open. The exact range will vary depending on your VoIP system.

Hence, if the RTP ports are not open, you can experience a "working" system, but with a complete lack of audio.

Also, this should not be possible, right?

b59dd3a3-ac9d-4c42-89f7-6bf3dbd29f62-image.png

172.17.1.27 is a Server on the IPsec-Side, not an OVPN-client.
Why did this appear as src on the ovpns1 Interface...

@steveits Thanks for your reply. I am aware of the changes. I was initially on 2.4.5, then went to 21.02-p1, and am currently on 21.02.2.

As mentioned, the issues started after the 'upgrade' from 2.4.5. But a few details that I will add since I was thinking back:

Very rarely, the speed on transfers does go up to the expected speed of around 40 MB/s and lasts a few minutes, but then returns to the around 8 MB/s. Unfortunately didn't catch the logs when this happened.

Also, the logs look normal, just the dashboard checking the IPsec status in the normal fashion.

CPU usage does rise when Async is turned off, but speeds stay basically the same regardless.

The issue is not like what is mostly mentioned by others, where the tunnel does not stay active. Mine does stay active, and is rather stable, its just that the speed is much slower than previous, with the same settings.

i updated an test pfsense to 2.6 dev version and the problem is solved.

@operator2024 Hi
I have same situation, no matter what I do I can't get a second phase 2 to come up when it uses a subnet that doesn't directly exist on a local interface.
could you please tell me what exactly you did so i can compare with my conf

in my case i have
Palo Alto --- IPsec ---- Pfsense --- IPsec --- AWS

Pfsense --- IPsec ---- Pfsense --- IPsec --- AWS

both don't work
could you please help

@werter OSPF - это уже лишнее в данной ситуации. Вопрос этот я решил через дополнительную фазу 2

@mainzelman Thanks for the reply.

Site B IPSec firewall rules were empty (I assumed this to be ok because Site A and Site B hosts can talk no problems)

I added the rule for Site B and it appears to be now working!
dd6e54f6-fa74-4b38-bf03-a8b3e6c04ec9-image.png

I knew it had to be something simple I missed, thank you!

hi all can i ask if is that possible when you used ipsec vpn in pfsense . im using vmware workstation in my laptop. when i tried to connect to another pfsense which is located to another site it doesn't work for me please help

My laptop connect to isp then i installed vmware workstation at my laptop then setup pfsense server.

Hard to see how that could be. The packet is arriving over the IPSec. TCP Syn packets are tiny anyway. But if you've seen something similar before I guess....

But that pass rule should match and clearly isn't. IP Options on it or something odd?

Steve