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.

@scorpoin Try to change the LAN rule to "any any" to include icmp in your rule. Ping is icmp.

up

just to reply to my own question: I exported the wrong certificate. I had to download the end-entity certs, which are auto generated, during the Site-to-Site VPN. Once I exported the the correct one, established the tunnel. -San

@mamawe Yeah the logs haven't been super helpful, without any traffic flowing there's really not much to look at. These 10 connections on the pfsense machine aren't currently active, we had to switch back to our old VPN server after we tried and failed to get traffic moving out of the tunnel.

@bp81 I would also recommend going with VTI mode as @dotdash proposed. You can then use gateway groups for the routing and avoid the routing process.

@byte0 said in DNS Resolver forward over IPSEC site-to-site VPN: All is well. Yup, it's best to be the master of your system, pfSense does not invent new things, it just implements what we already knew.... Thanks for your follow up