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.

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

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

910228ad-8ee2-402d-a65b-542406572546-image.png

817c969c-3984-4f91-bba1-7499632fa1c6-image.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

With some assistance from pfsense support, and my mate Brett (thanks Brett!!!!)

It has been identified that FreeBSD has a limited on interfaces and will not accept interfaces numbered above 32767, so an interface number of 52000 is impossible.

I have created a bug report:
[https://redmine.pfsense.org/issues/9592](link url)

Brett has written a pull request that basically drops the ipsec vti interface creation padding from 000 to a single 0 and thereby changes the maximum number of vti interfaces from 32 to 3276.

[https://github.com/pfsense/pfsense/pull/4071](link url)

Looks like this will get fixed in time.

I think I like the DMZ option better, I will check that out.

Thanks for the input.

D.

My temporary solution was to manually remake all of the SITEB.local DNS entries in my local DNS (at site A) using the VPN ip addresses.

This seems to be working fine for the most part, but I will be looking to move one of the networks to a different subnet in the near future to avoid all of these issues.

@jkamal many thanks for the link 👍

Thank you very much bouke for sharing.

Your settings are quite similar to ours and we will probably follow you in using AES256-GCM 128 bits instead of AES128-GCM 128 bits. But we will probably skip hashing for Phase 2.

Phase 1
Key Exchange version: IKEv2
Encryption Algorithm: AES128-GCM
Key length: 128 bits
Hash: AES-XCBC
DH Group: 14 (2048 bit)
Phase 2
Protocol: ESP
Encryption Algorithm: AES128-GCM 128 bits
Hash Algorithms: None selected
PFS key group: 14 (2048 bit)

No hashing is selected for Phase 2 because both the book and online documentation say "With AES-GCM in use, no hash is required. " and "When using AES-GCM, do not select any Hash Algorithm entries as AES- GCM already performs hashing." respectively for Phase 2.

We are using a Protectli device:
Firewall Micro Appliance With 4x Intel Gigabit Ports, Intel Atom E3845, AES-NI, 8GB RAM, 128GB mSATA

CPU Type Intel(R) Atom(TM) CPU E3845 @ 1.91GHz
4 CPUs: 1 package(s) x 4 core(s)
AES-NI CPU Crypto: Yes (active)
Hardware crypto AES-CBC,AES-XTS,AES-GCM,AES-ICM
Version 2.4.4-RELEASE-p3 (amd64)
built on Wed May 15 18:53:44 EDT 2019
FreeBSD 11.2-RELEASE-p10