@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

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

think I found the resolution to my problem using post below. Set local Network to 0.0.0.0/0 and all seems to be fine now https://forum.netgate.com/topic/137737/mobile-client-ikev2-vpn-access-to-remote-network-ipsec/2

Also see this post, it is very similar to what you're trying to do and the OP lays out his solution nicely. https://forum.netgate.com/topic/143368/route-traffic-between-two-ipsec-tunnels/6

Are the subnet masks configured correctly on the target PCs? I just ran into this after changing our entire network subnet - some of the devices I had not yet rebooted were still on the old subnet. D.

Hi @jimp Here it is the status page while dashboard widget shows nothing and 0 [image: 1559775164193-76f14a97-d7c2-4fc2-b356-9465c40b2cd4-image.png] [image: 1559775209528-62ba11c3-f54b-4254-affa-16f0dac950fa-image.png] [image: 1559775236914-64183dc2-2a7d-4d27-a9c2-046227b27b82-image.png] [image: 1559775265919-3790afc4-708d-42c8-a634-07720376b4ae-image.png] [image: 1559775291462-773313d1-8653-440d-a204-bda0203f99be-image.png] [image: 1559775302193-5b97d0e9-affa-4f41-b10d-a77e1f4325fa-image.png] [image: 1559775313443-8dd40b47-0d3b-4359-886e-917f90d247f8-image.png] Thanks!

I closed that out since it's essentially a duplicate of #9111 You can apply the commit ID on that issue on 2.4.4-p3 to pick up the fix there.

@ngoehring123 said in NAT over routed VTI: @under_tow I reported this back in March. https://forum.netgate.com/topic/141613/can-i-route-internet-traffic-from-site-b-through-site-a-via-ipsec-vti Unfortunately no resolution that I'm aware of. Thanks, similar issues, GRE over IPSEC could work, but too many changes in our application for that for now.