IPSec / strongswan errors

[mimugmail]

Connection method is respond only.
Are you sure this is a mobile policy?

well, I followed
https://docs.opnsense.org/manual/how-tos/ipsec-rw-srv-mschapv2.html and
https://docs.opnsense.org/manual/how-tos/ipsec-rw-w7.html
so it should be a mobile policy?

Maybe you already have one and added a second P1?

No, there is only one P1 defined

So in the overview of IPsec : Tunnel Settings it's labeled as "Mobile Client"? Then set the connection method to default and not start immediate should be sufficient

[schnipp]

As mimugmail already mentioned for roadwarrior you need to set the start_action to "default" (or "none"). Additionally, if authentication fails, please remove "my identifier" in phase 1.

[BSAfH42]

As mimugmail already mentioned for roadwarrior you need to set the start_action to "default" (or "none"). Additionally, if authentication fails, please remove "my identifier" in phase 1.

thanks!

yes, it is marked a s as Mobile Client

I set the start action to "default" und changed "my identifier" to "automatic" (there is no "none").

Stil does not work, but it's a different error

Code: [Select]


Date
Severity
Process
Line
2023-03-29T08:08:22 Informational charon 08[NET] <2> sending packet: from 192.168.80.2[500] to 192.168.80.105[500] (36 bytes)
2023-03-29T08:08:22 Informational charon 08[ENC] <2> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
2023-03-29T08:08:22 Informational charon 08[IKE] <2> no IKE config found for 192.168.80.2...192.168.80.105, sending NO_PROPOSAL_CHOSEN
2023-03-29T08:08:22 Informational charon 08[ENC] <2> parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
2023-03-29T08:08:22 Informational charon 08[NET] <2> received packet: from 192.168.80.105[500] to 192.168.80.2[500] (1104 bytes)
2023-03-29T08:07:44 Informational charon 13[IKE] <con1|1> unable to resolve %any, initiate aborted
2023-03-29T08:07:44 Informational charon 14[CFG] received stroke: initiate 'con1'

and the Windows client says "Fehler in der Richtlinienübereinstimmung"

[mimugmail]

So, your WAN Interface is 192.168.80., you have a gateway like .1 and your test client ist on the same net with something like .5?

[BSAfH42]

So, your WAN Interface is 192.168.80., you have a gateway like .1 and your test client ist on the same net with something like .5?

the WAN interface is 192.168.178.3, the gateway to the outside world is 192.168.178.1 (Fritz!Box)
the LAN interface is 192.168.80.2 on the OPNsense firewall

the test client is either 192.168.80.x (LAN) or in 10.0.8.x (OpenVPN VPN, OPNsense is the OpenVPN server), this is just for test for mobile clients outside the LAN.

The real application would be a road warrior with any external address. The Fritz!Box forwards everything from external addresses to the OPNsense box (in Fritz!Box terms: "exposed host").

[schnipp]

I don't really understand what you try to do. IPsec has nothing to do with OpenVPN, these are completely different technologies. Regarding IPsec the client has to connect to the Opnsense endpoint 192.168.178.3

[BSAfH42]

I don't really understand what you try to do. IPsec has nothing to do with OpenVPN, these are completely different technologies. Regarding IPsec the client has to connect to the Opnsense endpoint 192.168.178.3

well, I do know that OpenVPN is a completely different technology. For this purpose, the OVP network is just another network from where connections can come in.

And yes, the IPSec clients do connect to 192.168.178.3, because everything coming from the outside world is forwarded by the FritzBox to the interface WLAN on OPNsnse, which has 192.168.178.3

so, I do not understand  what you are trying to tell me?