IPSec Connection Between Two OPNsense Firewalls

[spetrillo]

Hello all,

As the title says I am trying to activate an IPSec connection between two OPNsense 23.7.9 firewalls. When I activate the phase two I am getting the following:

2023-12-09T18:42:11-05:00   Informational   charon   15[NET] <con2|1> sending packet: from 108.30.68.128[4500] to 68.129.95.196[1024] (96 bytes)   
2023-12-09T18:42:11-05:00   Informational   charon   15[ENC] <con2|1> generating CREATE_CHILD_SA response 716 [ N(TS_UNACCEPT) ]   
2023-12-09T18:42:11-05:00   Informational   charon   15[IKE] <con2|1> failed to establish CHILD_SA, keeping IKE_SA
2023-12-09T18:42:11-05:00   Informational   charon   15[IKE] <con2|1> traffic selectors 192.168.2.0/24 === 10.0.1.0/24 unacceptable   
2023-12-09T18:42:11-05:00   Informational   charon   15[IKE] <con2|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

I thought I had the phase twos setup correctly but I guess I am missing something. The traffic selectors as being unacceptable I do not understand.

Steve

[netnut]

2023-12-09T18:42:11-05:00   Informational   charon   15[IKE] <con2|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding[/b]

This mesagge is just informational, I believe FreeBSD doesn't support TFC Padding (not sure), but harmless.
Your subnet configuration probably mismatches.

Could you post your IPSec config from both boxes ? (please remove pre shared keys, etc and/or obfuscate your ip addresses).

Code: [Select]

cat /usr/local/etc/swanctl/swanctl.conf

[spetrillo]

2023-12-09T18:42:11-05:00   Informational   charon   15[IKE] <con2|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding[/b]

This mesagge is just informational, I believe FreeBSD doesn't support TFC Padding (not sure), but harmless.
Your subnet configuration probably mismatches.

Could you post your IPSec config from both boxes ? (please remove pre shared keys, etc and/or obfuscate your ip addresses).

Code: [Select]

cat /usr/local/etc/swanctl/swanctl.conf

Apologies for the late reply. We had a couple of deaths in our extended family and I was just able to focus back on this. Attached are the screenshots from site A and site B. Site B phase 1 and 2 are actually two screenshots each, as my monitor in site B is small.

[spetrillo]

Part 2...

[spetrillo]

Part 3...

[Monviech (Cedrik)]

Try to change the traffic selectors on both sides to only single IP addresses to troubleshoot.

For example (use fake IP addresses that don't exist):

First Site:
Local Net: 172.16.56.1/32
Remote Net: 172.16.56.2/32

Second Site:
Local Net: 172.16.56.2/32
Remote Net: 172.16.56.1/32

Test if that still makes the traffic selectors unacceptable.

[netnut]

Apologies for the late reply. We had a couple of deaths in our extended family and I was just able to focus back on this. Attached are the screenshots from site A and site B. Site B phase 1 and 2 are actually two screenshots each, as my monitor in site B is small.

My sincere condolences to you and your family.

Your auth & network settings are looking ok, the only "thing" I could spot is that you're using DynDNS identifiers. You might facing a problem where your IPsec peer couldn't match this identifier with your traffic selectors.

An easy way to debug this is leaving all your settings "as-is", only change your identifiers to static IP's at both sides and restart your IPsec connections and check if the tunnel is working this way.

[spetrillo]

My sincere condolences to you and your family.

Your auth & network settings are looking ok, the only "thing" I could spot is that you're using DynDNS identifiers. You might facing a problem where your IPsec peer couldn't match this identifier with your traffic selectors.

An easy way to debug this is leaving all your settings "as-is", only change your identifiers to static IP's at both sides and restart your IPsec connections and check if the tunnel is working this way.
[/quote]

Thank you for your wishes...

OK so I made the changes and went back to the IPs and took out the DDNS names...with no such luck. I am seeing some weird errors on the site A side:

2023-12-27T18:11:41-05:00   Informational   charon   05[NET] <con2|1> sending packet: from 108.30.68.128[4500] to 68.129.95.196[4500] (96 bytes)   
2023-12-27T18:11:41-05:00   Informational   charon   05[ENC] <con2|1> generating CREATE_CHILD_SA response 3 [ N(TS_UNACCEPT) ]   
2023-12-27T18:11:41-05:00   Informational   charon   05[IKE] <con2|1> failed to establish CHILD_SA, keeping IKE_SA   
2023-12-27T18:11:41-05:00   Informational   charon   05[IKE] <con2|1> traffic selectors 192.168.2.0/24 === 10.0.1.0/24 unacceptable   
2023-12-27T18:11:41-05:00   Informational   charon   05[IKE] <con2|1> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding   
2023-12-27T18:11:41-05:00   Informational   charon   05[ENC] <con2|1> parsed CREATE_CHILD_SA request 3 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]   
2023-12-27T18:11:41-05:00   Informational   charon   05[NET] <con2|1> received packet: from 68.129.95.196[4500] to 108.30.68.128[4500] (496 bytes)   
2023-12-27T18:11:26-05:00   Informational   charon   05[NET] <con2|1> sending packet: from 108.30.68.128[4500] to 68.129.95.196[4500] (96 bytes)   
2023-12-27T18:11:26-05:00   Informational   charon   05[ENC] <con2|1> generating CREATE_CHILD_SA response 2 [ N(TS_UNACCEPT) ]   
2023-12-27T18:11:26-05:00   Informational   charon   05[IKE] <con2|1> failed to establish CHILD_SA, keeping IKE_SA   
2023-12-27T18:11:26-05:00   Informational   charon   05[IKE] <con2|1> traffic selectors 192.168.2.0/24 === 10.0.1.0/24 unacceptable   

The traffic selector unacceptable is something I have never seen, but here is some additional information. Site A firewall is directly connected to the ISP connection. Site B firewall has an ISP router in front of it, but is setup to be a DMZ host on the ISP router. I am wondering that I am getting the traffic selector unacceptable bc Site B is behind a router?

[netnut]

Quick Note: You've posted public IP's and PSK's. I can't judge if they are real, if they are please change your PSK ASAP !!!

Back to your problem, is 10.0.1.0/24 directly connected at site B ?

[spetrillo]

Yes 10.0.1.0/24 is the LAN network on the Site B firewall, with the firewall being 10.0.1.1.

[netnut]

I am wondering that I am getting the traffic selector unacceptable bc Site B is behind a router?

Yes, if Site B's upstream IP is private (NAT as DMZ host from router) but the traffic selector is for the Public IP you might see this "unacceptable" message.
I don't have a direct answer what to change in the GUI though, what could help is converting the "old" OPNsense IPsec config to the new-style in the GUI and c/p your "raw" strongswan config (you need to that that anyway at some point in time). You now get the new strongswan "connection" style configuration and see how the remote TS is configured in there.

Code: [Select]

cat /usr/local/etc/swanctl/swanctl.conf

[spetrillo]

I am wondering that I am getting the traffic selector unacceptable bc Site B is behind a router?

Yes, if Site B's upstream IP is private (NAT as DMZ host from router) but the traffic selector is for the Public IP you might see this "unacceptable" message.
I don't have a direct answer what to change in the GUI though, what could help is converting the "old" OPNsense IPsec config to the new-style in the GUI and c/p your "raw" strongswan config (you need to that that anyway at some point in time). You now get the new strongswan "connection" style configuration and see how the remote TS is configured in there.

Code: [Select]

cat /usr/local/etc/swanctl/swanctl.conf

Thanks...I think I am going to abandon this and go back to Wireguard as the preferred technology for C2S and S2S connections.

I see the difference in IPSec. I am an old school Cisco guy, so tunnels are my jam. Moving to the connection based way of thinking is a bit confusing to me but I am getting it.