@polka44 I'm not sure IPv4 will work behind CG-NAT but IPv6 should from what little I understand.

IPsec Site-to-Site VPN Example with Certificate Authentication

IPsec Site-to-Site VPN Example with Pre-Shared Keys

Site to Site VPNs on pfSense

@shellbr There is another thread going on about this. Someone suggested a script.
https://forum.netgate.com/post/992563

@cre8toruk
There is no problem creating a separate site to site tunnel.

@froussy Hi, may be IPSEC (VTI) + OSPF/BGP???

@digitalcomposer

So what is the problem with IPSEC and Crypto AES-GCM??

I try with WireGuard and the SITE TO SITE speed is 800Mbit/s and with IPSEC 23Mbit/s.

This post was flagged as spam so I can't edit out the redundant image, sorry.

@metisit
A little late on this reply, but for anyone coming across this- that link concerns racoon and not strongswan.

@ralphandreas

Hi we have the same problem with 2.5.2 it is not better.

@cybertivo did you ever get anywhere with this. I have some traffic passing but seems like traffic initiated from at&t end is where most of the problem lies.
I thought static IPs would help, but no such luck so far. This same tunnel config was previously working when connected to cable modem.

You can install the System Patches package and then create an entry for 6cfa9d7498be390314b93fa40aea1704eb5a8eae to apply the fix.

@jimp Thanks for sharing your config. I've essentially duplicated this, tried different crypto, re-exported certs and putting them into a new config profile for iOS.

When I look at a pcap from pfSense, I can ping the mobile client from a host behind another subnet and even see ICMP requests going out to the mobile client with no response on that IPsec interface.

All I can deduce is that it must be an iOS bug that when the P1 is built over IPv6, some traffic is lost. I'm running 14.6 here, but with 14.7 due to be released imminently and the 15 public beta out, I may load that onto a test device and see if it's something they've fixed or open a feedback ID for it.

Aaaaand pinging beyond the Azure host was, as per my gut feeling, I shouldn't have been relying on the little IP forwarding switch in Azure and it was solved by enabling IP forwarding on the Azure host directly:

sudo nano /etc/sysctl.conf net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 sudo sysctl -p

Source: https://www.tecmint.com/setup-ipsec-vpn-with-strongswan-on-debian-ubuntu/

@atreyumu interesting. I wonder if it works if you leave it as network but then put in the device IP address with a /32. Basically you’re saying let out this network of 1 device. I’d have to dig around a bit if that doesn’t work. @jimp seems to be the IPSec guru on the Netgate side but can’t speak to his availability/interest in commenting. He keeps himself busy from what I see.

After some reading I think these are "out of state" connections and they are logged by the default deny rule.

Question: how can I make a rule to filter out these "out of state" connections going to that one ip address?
A rule with the option for logging turned of, so the packets don't hit the default deny.

I'm trying to edit this post as solved , but failed to edit keep getting popup message you can edit post from 36000 hrs .

Any way I use NAT/BINAT option again in phase-2 of ipsec.

Local : 172.16.190.0/24
NAT-BINAT : 192.168.3.2/32
remote : 192.168.3.0/30

that's all and reconnect the ipsec tunnel and every thing worked like a charm . I didnt add any firewall extra rule any where .

Regards

@mfld It is indeed!

There are two ways I'd approach this. The quicker way is to look for clues in the firewall log on both ends of the IPSec tunnel. If that doesn't yield anything, then go through the process, step by step, of what has to happen for a workstation to update group policies and try to determine where the break is.

For the first method, make sure pfSense is logging traffic handled by all firewall rules. You'll probably want to turn this off when done because it can get voluminous (unless you have a syslog server that stores them for you, in which case, log away). Also make sure you are logging on both pfSense boxes in either end of the tunnel.

Have the affected workstation run a gpupdate. After it fails, check the firewall log in pfSense at both ends of the tunnel. Look for traffic to or from the DC's IP address being blocked. The log can be found is Status -> System Logs -> Firewall. You can Ctrl+F search the page for the DC's ip address to find what you're looking for pretty quickly.

This will tell you if a firewall rule is blocking the traffic.

Now, failing that, you'll need to do a more in depth look into the problem.

Without seeing your environment it's hard to say, but most AD related problems can be traced to DNS resolution problems of some kind. One cause of that is firewall rules blocking traffic, which the first step should eliminate as an issue.

Try running nslookup <domain.com> from command prompt on the affected workstation. If you do not get back your DC's IP address, then you have a DNS resolution issue. There are several causes of DNS issues. Check the affected workstation's DNS Server addresses, and then make sure each of those DNS servers are answering DNS requests. Use nslookup <domain.com> <ip address of DNS server> to test each one. One problem I've seen is if you have your DC as primary DNS server and then your ISP's public DNS server as a fallback, you can get in a situation where name resolution to internet sites will work but resolution to internal hosts won't. If your primary DNS server (your DC in this case) is not answering DNS queries from your workstation, for whatever reason, then the ISP's DNS server might be queried instead; the ISP's server won't be able to resolve internal host names. This would break communication between your workstations and DCs through an IPSec tunnel. In this case you'd want to determine why the DC is not answering DNS requests. This can be firewall issues in pfSense, it can also be Windows Server Firewall issues on the DC as well.

This is a good starting point. Verify that DNS resolution works as expected and correct the issue if it doesn't.