In the Advanced Settings tab of the IPSec tunnel under Advanced IPSec Settings change "Configure Unique Ids as " from Yes to Never.
This should ensure that for each new connection it doesnt kill the previous connection for same user.
Description of Setting
"Whether a particular participant ID should be kept unique, with any new IKE_SA using an ID deemed to replace all old ones using that ID. Participant IDs normally are unique, so a new IKE_SA using the same ID is almost invariably intended to replace an old one. The difference between no and never is that the old IKE_SAs will be replaced when receiving an INITIAL_CONTACT notify if the option is no but will ignore these notifies if never is configured. The daemon also accepts the value keep to reject new IKE_SA setups and keep the duplicate established earlier. Defaults to Yes."
I am just trying to ping both ways. I can ping from the Windows client to Pfsense box, but not from the LAN on the Pfsense box to the Client. The client is on a its own dynamic IP network with a small router. The router has IPsec passthrough enabled.
I added the following IPsec rule and Phase 2 Tunnel
pfSense can handle all this pretty well. It gives you full control which traffic to route out to which gateway. You can determine this by source IP or / and ports or destination IP or or / and ports or both.
Just a few firewall rules on a single place.
And the nicest part, it can failover the upstream traffic to the other WAN in case of a dropout of the primary connection. Also it's possible to load balance all upstream traffic permanently.
I can't see any reason for running an additional router for VPN only.
Possibly one more clue to the puzzle. Looking at the status page of the local side when trying to connect, this is what I end up seeing:
There ends up being 2(!) connections which show up. The only difference appears to be the "NAT-T" behind the host on the generated connection. I'm guessing that's because it's detecting a NAT at the remote end? Possibly the ISP using NAT and screwing up the communication between both points (thus causing decryption to fail)?
@nocling I have not activated MOBIKE. From my point of view, this is not necessary for a site-to-site VPN connection.
Here are my P1 Settings:
Screenshot 2023-01-29 150303.png
Here are my Advanced IPsec Settings:
Screenshot 2023-01-29 150111.png
I also activated Asynchronous Cryptography, but I didn't see any advantages during testing, so I deactivated it again.
I am at a loss and do not know if the problem is due to the pfSense settings. With the Netgate 1537, do drivers for the hardware also have to be updated in addition to the pfSense? Or is this done with the installation of pfSense? System -> Netgate Firmware Upgrade shows that this function is not available for this hardware.
But why did the first P2 activate without that command ???
Is there some default/special handling of the first P2 ?
Yes, there is.
When connecting, the first P2 SA entry uses DH information from the parent P1, and not its own PFS value. This isn't specific to pfSense, it's part of how IPsec operates.
It will use the P2 PFS value for the additional P2 entries and also when rekeying, so it may have failed to stay established over time as well.
You'll see this sometimes on the IPsec status when a tunnel connects first and it doesn't show the PFS value in the P2 status for the first configured P2 initially, but it will after a while when the tunnel rekeys.
I'll just continue on from here. I'm not following your comments really. His UDM is managing VLANs and networks for his clients. I need a connection to his UDM to get my VPN and network routed to and from his UDM. The VPN is to get to discrete networks in two geographically dispersed locations to communicate directly. I have no idea how else it would be done.
Appreciate everyone's input. Although I'd still be interested to know if pfSense can handle a hair-pin situation with VPN or if it really needs to cross interfaces to operate at all.
Unfortunately, I don't have the experience to discuss VTI in depth. I am grateful for the observation.
However I managed to get my gateway rule working when I set a destination. And to point to the world I use something like "!127.0.0.1". After that the rule started to obey and my LAN started to go out through the gateway described in the rule.
However I'm afraid of the way this is configured, I don't know the impact of this for future cases. My only limitation now is my partner's sonicwall firewall that when he selects Tunnel Interface (VTI) he cannot define "Local Subnet" and "Remote Subnet". It's like it only accepts 0/0 for 0/0.
I did another test that was to configure phase2 with a different "Remote Subnet" with any network that doesn't even exist for us, without changing the sonicwall side and phase2 connects. So it seems that sonicwall's behavior when as a tunnel interface is to accept whatever network I configure on my side. Of course, for it to work I must configure the right networks, but this explanation is just for information purposes. Ahh, and I realized that because before I tried to connect several phases2, one for each network and only one worked. So I did the test above and it worked.
What I'm going to do now is create, together with my partner on sonicwall, several phase2s, one for each network I need to connect, and then try to redo all the phase2s I need by correctly defining the destination networks I need.
@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.
@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.