@viragomann - the packet sniffing and increasing the log detail for ipsec did the trick - two issues: I had a couple of machines with no gateway defined. This was not an issue for local traffic but creates an issue for the traffic back to the IPSec devices. In all of the testing I had left the Phase 2 local subnet set to just one of the networks. Changing to Network 0.0.0.0/0 did the trick. Thanks for the pointers.

@timatleeTry turning the PFS key group on P2 to off and see what happens. I have a couple of IPSec connections with Fortigates, 1 with 4 SA's but that one has PFS key group set to off. Unless I am mistaken, by default, the DH for P2 inherits the DH from P1 unless specified differently. I also set my time lifetime 10% higher than the FortiGate, which seemed to help a lot.

Ok, I was stupid. My Phase2 was not configured correctly. "Local Network" was set to ::/128 when it should have been ::/0 It's now working

@lukepicci Just for reference, i raised a ticket: https://redmine.pfsense.org/issues/13788

@lk777 I agree completely. it is confusing. The documentation says one thing but as you can clearly see choosing either one the tunnel still comes up. Would be helpful to have an info button somewhere that quickly shows the pros/cons of selecting each one.

@heinola Think its like: broadcast = hey everyone ( please sir can i have some more ) p2p = hey you xxx.xxx.xxx.xxx ( give me what i want ) or am i way way off

@enesas What you might miss is an outbound nat. When all traffic for a remote user is router over VPN, then you need to make sure that client's private IP is translated on the pfsense to the wan or alternative public IP, within Firewall NAT Outbound configuration. On client end routing table will confirm if all client traffic is routed over the VPN (Windows command "route print", or Linux "netstat -r")

@planedrop When I don't specify the peer IP manually I do get authentication failure replies back to the initiator box as well, so seems one pfSense unit isn't actually using it's IP as the identifier when it's supposed to, which is why I think this might be a bug. Will try to do some more digging but really curious if anyone has seen this before.

An update on this; the above settings still being the same, I cannot get the connected devices to use the firewall/DNS resolver when doing a lookup/attempting to connect to any of the devices on the LAN via hostname. Also attached a screenshot of the DNS Resolver settings in case I'm missing anything. I just get the generic "A server with the specified hostname could not be found" message when trying to connect. [image: 1671026619921-dnsresolvergeneral.png] For reference, the Netgate itself is able to ping anything in the DNS Resolver list by name without any issue: [image: 1671029034851-netgatednstest.png]

I finally got a working test without the issue. Issue only occurs with RADIUS authentication and EAP-RADIUS. EAP-MSCHAPv2 with local user/PSK list does not have the issue.

@samir-elfadil said in ipsec tunnle to virtual ip: what am I missing out :) If you tell us, which address you need to access from where and how you can access it from the local firewall and what you have configured currently, maybe somebody can answer your question.

@michmoor 172.25.0.1 is a virtual IP for the satellite, it's routed to rocket which handles the communication with the satellite. Indeed, if I send packets destined to the the satellite from pfsense B they arrive to rocket and get to their destination, but from site A they don't even reach rocket..

@jlw52761 Please test. Im curious if this is possible.

I had to let it percolate a bit to remember that way back when this was set up the PowerShell script adds a route for the subnet: Add-VpnConnectionRoute -ConnectionName "name" -DestinationPrefix 10.2.2.0/24 IPsec tab FW blocks from source IP to each subnet work great. Thanks,