Highly doubtful those are filling your RAM but it could be causing issues. When a tunnel is rekeyed the old one is kept around until its lifetime expires. I would look at the IPsec logs and see who is initiating the tunnels when one already exists. When that is determined, attempt to figure out why they are doing that.

Not true. right = is the address being connected to/from rightid = is the identifier the other side is expected to present If an FQDN is used in the Remote Gateway of a connection, the FQDN is used as right = that.fqdn.tld Strongswan says this: If an FQDN is assigned it is resolved every time a configuration lookup is done. If DNS resolution times out, the lookup is delayed for that time. The rightid could be pleasemakemyipsecwork as long as both sides agree. In dyndns situations it is usually necessary to set a specific identifier in My identifier (usually something like the dyndns host name of that side) on the side or sides that are suffering with dynamic addressing with a matching Remote identifier on the other side.

If pfSense is not the default gateway of the host that you are adding that route to, then you need the route there. IP Networking 101 and nothing to do with pfSense.

Hmm, connecting directly from the Linux box as a client seems far more likely to work in all honesty. If that can't be made to work I'd be very surprised to see pfSense able to connect. Steve

opvns1 looks like Open VPN not IPSEC. If you use IPSEC you should configure firewall rules on the IPSEC interface. If you use OpenVPN you should configure firewall rules on the OpenVPN interface. https://docs.netgate.com/pfsense/en/latest/book/openvpn/assigning-openvpn-interfaces.html Regards, Corrado

Yes, you can have site2site IPSEC and Mobile Clients on a single WAN at the same time. Did you check "Enable IPsec Mobile Client Support " in IPSEC/Mobile Clients? https://forum.netgate.com/topic/113227/ikev2-vpn-for-windows-10-and-osx-how-to Regards, Corrado

It appears solved now: I disabled mobile support, deleted the mobile IPsec phase 1 and recreated the client VPN. Had this suspicion because the phase 1 entries showed up as "any" for their remote identity. I guess the problem is, that I defined the network of the mobile phase 2 as 0.0.0.0/0 because I want to route all client traffic through the VPN. And I use VTI for S2S, which creates generig 0.0.0.0/0 phase 2 entries.

And managed not to fat-finger that too. Just poking fun man. Glad you found it. We have ALL done that and taken far too long to see it.

@PedroBelliato said in IPSEC Site-to-Site VPN (tunnel does not close): [HASH N (AUTH_FAILED)] 2 Whenever you receive an AUTH_FAILED notify you should check the other peer's log file. There should be an explanation there why the authentication failed. [image: 1561486239360-afdc166c-f4cc-428f-9511-a65d93e37fa9-image.png]

Hi guys, Any ideas why it doesn't work? What's the reason of appearing such logs in pfSense: Jun 23 12:49:06 charon 15[NET] <con2000|28> sending packet: from 154.61.34.210[500] to 195.177.74.126[500] (108 bytes) Jun 23 12:49:06 charon 15[IKE] <con2000|28> activating new tasks Jun 23 12:49:06 charon 15[IKE] <con2000|28> nothing to initiate Why there are no outgoing ESP packets from pfSense and why IPSec SA counters doesn't increased?

@runaway19 said in Ipsec site to site problem web server: The web server network is internal, not public. My question was, how do you try to access it? By its public hostname or by its public IP or by its internal hostname or IP?

Have you managed to resolve the issue?

@claferriere Hey I see 2 solutions to this problem make changes to the PFSense configuration file so that you can use the option %any in the remote gateway ip address settings ( this will allow you to connect from any ip address) - this solution has been tested and works [image: 1561207575266-fcc69529-aa33-4ab6-a060-b854fb9f9fd9-image.png] 2.Strongswan can use the updown script when establishing or disconnecting a connection. You can write a script that, if the connection down, will run the command ipsec reload , which will reload the configuration file . - This solution is experimental , I did not test it [image: 1561207704342-910228ad-8ee2-402d-a65b-542406572546-image.png] [image: 1561207186633-817c969c-3984-4f91-bba1-7499632fa1c6-image-resized.png]

Thanks Pablo. Good to have in case we ever move to an HA setup with Google VPN. For anyone else that reads this, my posts were for the Classic Google VPN setup (non HA). One note I wanted to add, in the BGP settings in my instructions above, don't change the setting for "Redistribute connected networks" to Yes. When set to Yes this advertised our WAN network to Google and caused issues with hitting public facing servers we had in Google. Since we only have a few networks locally, I just manually defined those along with the BGP network 169.254.10.0/30 in the fields below that setting. The other option may be to change the setting to Yes and somehow mark it to ignore the WAN network, but I haven't looked into that.

@Konstanti Thank you so much for your help. Earlier route was not getting add for IPSec for ipsec statusall. I can see now roue is listed and IPSec communication is fine. Thank you so much for your help. Thanks, Kal