@viragomann Thank you! Do you know if the VPN will disconnect and reconnect if I add the second phase 2? I don't want to cause any disruption when I try it.

@viragomann Thank you so much, It's 100% correct I figured it out that's exactly what I have done now. And yes it's only access from one side. Thanks again appreciate your time

@oscar-pulgarin
"Any" just accepts any identifier. So it isn't verified.

By default IPSec use the interface address, which it is connecting through, as identifier and for incoming connections it expects to see the remote gateway IP.
However, since the endpoint gateway is behind a router, IPSec uses the internal IP 10.206.0.14, which your site doesn't expect and drop the connection.

But IPSec allows you to state a certain identifier IP. Also there are different identifier types.
So if the remote site is behind a NAT router there should be stated its public IP as its identifier.

Anyway if you have stated a certain remote gateway, IPSec only allows connection from this IP. So I don't think, "any" for the remote identifier is a security risk here.
But you can request them to configure their IPSec properly to use the public IP as identifier, or just enter 10.206.0.14.

@humaxoid
None of these. Best method is to add a phase 2 to the site-to-site for the mobile tunnel network. Remember to do this on both sites.
Also ensure that the remote network is routed over the mobile IPSec.

I also noticed this

Why the ID says "any identifier" if I established the IP in both?
d9a3b80c-6d46-495e-abc2-20f99c573b89-image.png

@datacare There are no responses from the opposite end. Remeber IKE uses UDP, and can transmit several packets it considers “data” without any preceeding “connection” being made as with TCP.
Notice there are no packets recieved from the other end - so you need to investigate that, and why :-)

@planedrop don't load pn the ipsec tunnel.

can you share P2 subnet/IPs of both end, and firewall rule configured on IPSec interface - both ends,

@rsdu Even though the documentation states that firewall rules are added automatically, firewall log shows that incoming traffic is blocked by the "default IPv6 incoming block" rule. I added UDP Port 500 and ESP to the ruleset and there we go ...

@Mr_JinX
system logs............
ipsec logs...........
Unless you didn't provide the logs on purpose its impossible to say why anything happens anywhere.

After taking the screenshot, and recognizing the mismatch between the ports, I've updated the PHASE1 settings on both ends, specifying just the NAT-T port.
0dbb0d4a-70c8-496a-87dd-bee9fa740865-image.png

Now, the ports looks coherent.
SITE A
5387557b-d330-43ec-a494-e44119f1e484-image.png

SITE B
a0791832-6b78-4a3a-a053-f749822d43b5-image.png

Now ping works :)
996ddfcd-d96a-4b60-9bb5-f194f3ed1fa9-image.png

08a81d89-236c-44e0-8ecc-26dc19d27d4e-image.png

Still open the question on why this port mismatch happened.....I've lost like 40 hours on this

@viragomann Thanks for helping me.

Your tip worked for me.

@lifeboy When editing the Phase one and Phase 2 settings, only one encryption settings is enabled in both:
AES256 and using SHA256 with DH14:

72a1546e-02d3-4f89-bebe-3fc688c05aec-image.png

937960d9-5daa-465f-a6f4-630ecdc079ac-image.png

@viragomann

Hello @viragomann

Please see details logs on attachment filelog-ipsec-details-pfsense.txt

Thank you for your help

Regards