@keyser

i found the issue after changing the Phase1 settings.
The CA import from wasn't successful.

After reimport... all works fine...

THX for your time and support...

Stefan

We figured it out thus I will be posting our solution here in case anyone finds the same issue in the future.

Basically once the DoT option is enabled unbound changes behavoir because of the way is implemented in pfSense software. See: https://redmine.pfsense.org/issues/13393

To make sure enabling DoT works, you should choose specific network interface(s) to which the DNS Resolver will bind when listening for queries from clients and not listening on ALL interfaces, i.e DNS Resolver > Network Interfaces > ALL , which is the default option for pfSense.

In short changing our DNS Resolver's listening interfaces from ALL to just the LAN, DMZ and localhost solved the issue.

Hope this helps,

Alejandro

I'm not an IPSEC expert, never actually used it.

In your log I could see any 'cert' related errors.
Only this one :

@thewaterbug said in Mobile User VPN failed w/Cert Expired; New Cert doesn't fix:

Aug 15 15:15:36 charon 07[IKE] <93> DH group MODP_2048 inacceptable, requesting MODP_1024

Who/what is charon ?

@bp81

I solved my own problem, and wanted to record the answer in case others have similar.

First, my initial assessment that the IP address of a Neighbor entry had to match the Router ID that was set on that neighbor's BGP service was wrong. It didn't work for me initially because I had some other things set wrong.

Here's how it's now working:

I setup the IPSEC connection between Hub and Branch 1 as described above. The transit network for this link is 172.16.0.0/30. Hub gets 172.16.0.1, Branch 1 get 172.16.0.2.

The connection between Hub and Branch 2 is similar. The transit network is set to 172.16.0.4/30. Hub gets 172.16.0.5, Branch 2 gets 172.16.0.6.

The router ID for all routers is set to the LAN IP address in BGP, NOT the transit network IP address.

Each Neighbor entry specifies the transit network IP. Ergo, Hub 1 has neigbor entries that specify 172.16.0.2 (Branch 1) and 172.16.0.6 (Branch 2).

The last setting, and this turned out to be the trick that made it work, is in the Neighbor settings in the Next Hop section. Took me a bit to find and identify this as the solution to my 'chicken and the egg' problem in my OP. In the Next Hop action, I set Next Hop Action to "Set (Peer Only)" and I set Peer to "Peer Address (set only)".

This setting is what got things going as expected.

7c08b0b6-27b0-4f6b-9303-d428db2ab2be-image.png

@keyser Oof. Sounds like I'm in unsupported configuration territory here.

I'll see how it performs in a lab.

@bbrendon said in IPSEC + VTI + IKEV2 - will not auto-reconnect:

Hi @jimp .

Regarding the "Keep Alive - Enable periodic keep alive check" option, should that be enabled on both sides or just the side initiating the connection?

Usually just the side initiating

@keyser @stephenw10 - I hope this little fix is not forgotten? I have seen no acceptance of the redmine ticket.

@betahelix You say your tried adding a phase 2, did you use the wireguard tunnel network? That's what you would need.
You can do a packet capture on the remote site and ping from the local. I'm guessing the packets are getting there but don't know how to get back. Adding the tunnel network will fix that.

@thale
You are most welcome and good luck with your implementation.
Happy to provide further feedback on my setup if you have specific questions.

@dotdash thanks for the feedback.

Just to follow up on this in case it helps someone else, I did get this working. I had upgraded my lab routers to 2.6.0 (which it looks like I left out of my original message), and then restored a backup from an earlier version (2.4.5 I think). Either the upgrade or the restore of the previous version's backup seems to have caused this (or the combination). I did a completely fresh install of version 2.6.0 and manually reconfigured it, and I didn't have any more problems.

@thale Thanks for giving me time really appreciate ur effort

@admiral_ackbar
Yes, you can have multiple phase 2 for different local subnets.
I think, that should work with routing the whole upstream traffic for only one subnet.

@shahidge4
The tcpdump from WAN is pretty useless, since the connection is established already.

Your P2 has a single remote IP. So the VPN will only allow access to this one.
Do a packet capture on the IPSec interface.

Ensure that the remote host does not block access from the remote network.