Sorry for the late reply... You are our hero! I feel kind of stupid, as we did not tested it like this. Best wishes, Yannick

https://redmine.pfsense.org/projects/pfsense/repository/revisions/f15fdef37ff7c1fcaecc73f2927ba1d7775032b0/diff It was WAN before. So no reason to change for me.

IKEv2 works for Windows (Powershell Commands needed + Regedit change), android (Strongswan app) and iOS (Apple Configurator 2).

It will reconnect when there is interesting traffic. It is generally imperceptible to the user. The IPsec logs will say exactly what is happening. Don't just change things unless the logs indicate what the problem is and whatever you change is related to that. https://docs.netgate.com/pfsense/en/latest/book/ipsec/ipsec-troubleshooting.html

@Derelict Thanks for your help.

The tunnel also didn't route IPv6 over itself, even though I had IPv4 & IPv6 P2s defined. Again, from the commandline I did this on one side: ifconfig ipsec1000 inet6 2600:3c01:e000:31e::2 prefixlen 112 and this on the other: ifconfig ipsec1000 inet6 2600:3c01:e000:31e::1 prefixlen 112 Giving me this: ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400 tunnel inet 96.126.96.153 --> 73.140.16.217 inet6 fe80::84b8:2eb3:a617:de8a%ipsec1000 prefixlen 64 scopeid 0x6 inet6 2600:3c01:e000:31e::2 prefixlen 112 inet 10.20.30.1 --> 10.20.30.2 netmask 0xfffffffc nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> reqid: 1000 groups: ipsec And IPv6 worked.

Something probably changed in the path MTU between the two sites. Try setting MSS Clamping to something like 1350 on both sides VPN > IPsec, Advanced Settings Note how the 192.168.148.10 site is reporting an 8960 MSS value. Someone playing with jumbo frames and screwed the pooch there?

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?