@gregoire This can only be done with BINAT in P2. However, it either requires that the local network and the NAT network have equal subnet sizes or the the translation network is a single address.

Searching with right keywords, I found the solution for the routing issue : https://docs.netgate.com/pfsense/en/latest/troubleshooting/ha-vpn-secondary.html I created the Outbound NAT as explained in the link above, and now the backup node is accessible from my remote location.

@viragomann I finally managed to do it by adding 10.10.10.0/24 to phase 2 at local and remote site. I should have been more concrete in the initial problem description. The problem was not, that I could not add a phase 2 entry at the remote site, but that there is another router behind the vpn remote gateway and the remote clients. And it would have been impossible for me to add routes on this router. Now I added 10.10.10.0/24 as phase 2 just to bring up the tunnel and force the kernel to route the traffic (DNS responses) over IPSec. In this configuration, native communication between 192.168.0.0/24 and 10.10.10.0/24 is still not possible, but port forwarding from 10.120.0.250>10.10.10.10 now works like a charm So it's more like a hack than a solution, but it's not stuppid als long as it works Thank you for your support and merry christmas!

@jcropsey-clearwave said in Opposite of BINAT: Hey frined, I'm facing with the same problem for quite a while now, did you manage to somehow handle this case? I think I got a solution to that.

I spent several hours in trial and error with Routed IPsec (VTI) but finally ended up in using (NATed) openVPN config behind the partner IPSec tunnel. The main issues I had was with a endpoint using dynamic IPs and the leck of knowlege how to use vti config if the other side uses P2 config without vti. It looks like pfsense is mixing up P2 phases when using 0.0.0.0 on the other side due to dynamic IPs. Ubiquity (on one partner side) is not supporting dynamic IPs at all when using VTI.

@restrictedr Routed IPsec (VTI) may work in your scenario but I had a hard time and ended up in using openvpn. The restrictions and/or best practices are not well documented and additonally will not work if you have endpoints using dynamic IPs

Custom script + cron do the job. When we I have a time will summarize and will provide more info for the script

@jimp Thanks for the help here, makes a lot more sense now, really appreciate it!! I'm sure keep alive is working then so must be DPD or the endpoint.

@gnatbite My solution is documented here. https://forum.opnsense.org/index.php?topic=25957.msg125506#msg125506

@jimp said in how to enable continuous IPsec S2S reconnection retries?: If the remote side initiates properly, it should respond. [image: 1639575921528-6f8e4b12-d9e8-434f-b595-0411d595e9a5-image.png] if other side's offline time not really long pfsense responds to IPsec tunnel requests as I can said from status page above. @jimp said in how to enable continuous IPsec S2S reconnection retries?: The firewall tries to source it from an address inside the local part of the P2, assuming there is an address on the firewall in that subnet. If there isn't an address on the firewall in the P2 then it can't send any traffic that would trigger the tunnel to initiate. thanks for this information, doing this immediately!

@alejjime Its on the pfSense toward the bottom of the Phase 1 page. :-) [image: 1639522844128-screenshot-from-2021-12-14-22-58-57.png]

Also this: Disabled "MOBIKE" on y.y.y.y (This feature was only enabled on y.y.y.y)

@periko Thought so. The issue is with ipsec configuration. Pls elaborate

@craigerr1 is P2P? Mobile? Have u open the rules in both sides to allow traffic on your firewalls->rules->ipsec? Regards!!!

@arobin Depends what you're trying to achieve. You didn't mention at all. Your existing rules on A allows access from site B 10.0.10.0/24 to site A 10.100.1.0/24. However, there is additionally a rule on DMZ at B needed for passing traffic to the remote site.

@alejjime Reviewing the pfSense configuration of my Azure network, I noticed the time zone was different than that of my client's servers, and I have already changed it, as well as that of my Windows server with the SFTP application, so they are already synchronized with my client's servers. I made that adjustment thinking that the date/time difference might generate an asynchrony problem, but the problem persists.