Traffic Selector unacceptable.

[mirtiza]

I am trying to establish IPSec VPN tunnel using IKE v2
after authentication i get this message on pfSense.
Feb 13 17:19:35 charon 13[IKE] <con1|40> traffic selectors 172.19.7.0/24|/0 === 192.168.1.0/24|/0 inacceptable
Feb 13 17:19:35 charon 13[IKE] <con1|40> failed to establish CHILD_SA, keeping IKE_SA
I am looking for some help.

[Konstanti]

@mirtiza

Check the phase 2 traffic selectors settings on both sides of the tunnel
or show the phase 2 settings here (on both sides)

[mirtiza]

[mirtiza]

@Konstanti for refrence i am attaching exact logs.
Feb 13 17:32:43 charon 05[IKE] <119> 103.7.77.89 is initiating an IKE_SA
Feb 13 17:32:43 charon 05[IKE] <119> remote host is behind NAT
Feb 13 17:32:43 charon 05[ENC] <119> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Feb 13 17:32:43 charon 05[NET] <119> sending packet: from 203.xxx.xx.134[500] to 103.7.77.89[5826] (276 bytes)
Feb 13 17:32:44 charon 05[IKE] <con1|109> retransmit 5 of request with message ID 0
Feb 13 17:32:44 charon 05[NET] <con1|109> sending packet: from 203.xxx.xx.134[4500] to 103.7.77.89[5870] (60 bytes)
Feb 13 17:32:44 charon 05[NET] <119> received packet: from 103.7.77.89[5870] to 203.130.23.134[4500] (212 bytes)
Feb 13 17:32:44 charon 05[ENC] <119> parsed IKE_AUTH request 1 [ IDi CERTREQ AUTH SA TSi TSr ]
Feb 13 17:32:44 charon 05[IKE] <119> received 1 cert requests for an unknown ca
Feb 13 17:32:44 charon 05[CFG] <119> looking for peer configs matching 203.130.23.134[%any]...103.7.77.89[Transport]
Feb 13 17:32:44 charon 05[CFG] <con1|119> selected peer config 'con1'
Feb 13 17:32:44 charon 05[IKE] <con1|119> authentication of 'Transport' with pre-shared key successful
Feb 13 17:32:44 charon 05[IKE] <con1|119> authentication of 'pfSense' (myself) with pre-shared key
Feb 13 17:32:44 charon 05[IKE] <con1|119> IKE_SA con1[119] established between 203.130.23.134[pfSense]...103.7.77.89[Transport]
Feb 13 17:32:44 charon 05[IKE] <con1|119> traffic selectors 172.19.7.0/24|/0 === 192.168.1.0/24|/0 inacceptable
Feb 13 17:32:44 charon 05[IKE] <con1|119> failed to establish CHILD_SA, keeping IKE_SA

[Konstanti]

This post is deleted!

[Konstanti]

@mirtiza
You have incorrectly configured tunnel parameters on the PFSense side
You set up a tunnel for the Road warriors(Mobile Ipsec), and you need to configure the site-to-site

https://docs.netgate.com/pfsense/en/latest/book/ipsec/site-to-site.html

[mirtiza]

Yeah i dont have static IP on both sides.
Site A has static IP and Site IP has dynamic WAN IP, as per my understanding site to site configuration is in case when both sides have static IP.
Please correct me if i am wrong.

[Konstanti]

@mirtiza

Openvpn - your solution

IPSec tunnel needs static ip addresses on both sides

[mirtiza]

This is the network i want to establish.

[Konstanti]

@mirtiza
openvpn

[mirtiza]

Okay but there is a guide for Digi Transport Cellular routers to do this.

They say its possible, i dont know if you can have a look.I am sharing the pdf as well.
http://ftp1.digi.com/support/documentation/AN_027_Configure_an_IPSEC_VPN.pdf

Than you.

[Konstanti]

@mirtiza Theoretically, this is possible to configure using PFSens strongswan) . I need to think

[mirtiza]

@Konstanti thank you so much for time. Please take your time i will be waiting for you. As per my understanding Road Warrior style VPN is for clients with dynamic IP which matches my case.

[Derelict]

No. You need to use a site-to-site to route tunnel networks like you are trying to do. Mobile IPsec assigns one and only one address to a connecting client. It doesn't "route" subnets like a site-to-site tunnel.

You need to work around dynamic IP addresses with something like dynamic DNS for each endpoint.

Nothing you come up with there will be perfect. Especially if the addresses simply change abruptly.

Set each side to update a Dynamic DNS entry pointing to their actual, routable, outside WAN address.

Tell each side to connect to the FQDN of the DynDNS entry on the other side.

Set each side to use their own FQDN as the IKE identifier locally, and the other side's FQDN as the remote identifier.