IPSec Certificate Based Connections DNS Resolution Issues

whoot · 6 August 2024 15:18

Recently (within the past 5 days), our IPSec Certificate Based connections suddenly have been unable to resolve addresses inside and outside of the local network, they have been working 100% fine up until this point. No firewall changes were made, no configuration changes updated, no other changes effected which may have lead to this.

We do have an IPSec PSK setup on our distributed systems and no impacts to this means of establishing an IPSec connection have been observed (all addresses can be resolved, all resources are working as they have been).

Our build is as follows

IPFire version	`IPFire 2.29 (x86_64) - core186`
Pakfire version	`2.29-x86_64`
Kernel version	`Linux *********.com
6.6.32-ipfire #1 SMP PREEMPT_DYNAMIC Mon Jun 10 19:01:56 GMT 2024 x86_64
Intel(R) Celeron(R) J6412 @ 2.00GHz GenuineIntel GNU/Linux`

A dump from the charon output for one of the certificates

Aug  6 11:00:14 ******* charon: 01[IKE] IKE_SA Palladium[58] established between ***.***.***.***[C=US, O=*************, CN=*******.*********.com]...***.***.***.***[C=US, O=*************, CN=Palladium] 
Aug  6 11:00:14 ******* charon: 01[IKE] scheduling reauthentication in 42263s 
Aug  6 11:00:14 ******* charon: 01[IKE] maximum IKE_SA lifetime 42803s 
Aug  6 11:00:14 ******* charon: 01[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ 
Aug  6 11:00:14 ******* charon: 01[IKE] CHILD_SA Palladium{11} established with SPIs cc79e766_i cb907f97_o and TS 0.0.0.0/0 === 192.168.128.1/32 
Aug  6 11:00:14 ******* charon: 01[IKE] CHILD_SA Palladium{11} established with SPIs cc79e766_i cb907f97_o and TS 0.0.0.0/0 === 192.168.128.1/32 
Aug  6 11:00:14 ******* charon: 01[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH CPRP(ADDR DNS) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ] 
Aug  6 11:00:14 ******* charon: 01[ENC] splitting IKE message (2642 bytes) into 3 fragments 
Aug  6 11:00:14 ******* charon: 01[ENC] generating IKE_AUTH response 1 [ EF(1/3) ] 
Aug  6 11:00:14 ******* charon: 01[ENC] generating IKE_AUTH response 1 [ EF(2/3) ] 
Aug  6 11:00:14 ******* charon: 01[ENC] generating IKE_AUTH response 1 [ EF(3/3) ] 
Aug  6 11:00:14 ******* charon: 01[NET] sending packet: from ***.***.***.***[4500] to ***.***.***.***[45259] (1248 bytes) 
Aug  6 11:00:14 ******* charon: 01[NET] sending packet: from ***.***.***.***[4500] to ***.***.***.***[45259] (1248 bytes) 
Aug  6 11:00:14 ******* charon: 01[NET] sending packet: from ***.***.***.***[4500] to ***.***.***.***[45259] (272 bytes) 
Aug  6 11:00:14 ******* charon: 09[NET] received packet: from ***.***.***.***[45259] to ***.***.***.***[4500] (113 bytes) 
Aug  6 11:00:14 ******* charon: 09[ENC] parsed INFORMATIONAL request 2 [ N(NATD_S_IP) N(NATD_D_IP) ] 
Aug  6 11:00:14 ******* charon: 09[ENC] generating INFORMATIONAL response 2 [ N(NATD_S_IP) N(NATD_D_IP) ] 
Aug  6 11:00:14 ******* charon: 09[NET] sending packet: from ***.***.***.***[4500] to ***.***.***.***[45259] (113 bytes)

As a troubleshooting effort, we did put a DNS rule in for IPSec RW connections that we would have at least hoped would have resolved the apparent resolution/timeout messages we are seeing when accessing a resource (inside LAN or to a WAN destination).

We even created another few Certificate based connections, each successfully establish a connection to the firewall, but none are able to resolve an address/host.

We must be missing something, but are seeking some guidance to resolve this ASAP

bonnietwin · 8 August 2024 12:56

Hallo @whoot

Welcome to the IPFire community.

You don’t have any error messages in the portion of the IPSec logs you have shown.

A more likely issue is that you have some problem with your DNS Server.

On the WUI menu Network - Domain Name System entry there is a Status section at the top left hand of the DNS Servers section. Is this showing Working in Green or Broken in red?

If you press the Check DNS Servers button do all of your selected DNS Servers sho90w a Status of OK in green or do some of them show Error in red?

whoot · 8 August 2024 20:15

Adolf, this is the output of our DNS Server Check

What we are able to do is establish a VPN connection, we just for some reason are unable to resolve any address internal or external from our cert based VPN (IPSec) roadwarriors. Only the PSK roadwarriors can function as usual.

bonnietwin · 8 August 2024 20:53

So you are saying that your PSK roadwarriors are able to resolve any address.
That would suggest that the DNS is working sufficiently.

Just as a confirmation check, disable all the DNS Servers that are shown as Not validating. Those DNS Servers are clearly not DNSSEC enabled which IPFire’s unbound DNS system requires, so you might as well disable them as they should never be used as their response will never be accepted by IPFire’s unbound DNS server.

With those DNS servers disabled then you would have three with an OK status.

Confirm if the Certificate based IPSec Roadwarriors are still having a problem to resolve URL’s.
If yes, the you will need to look through more of the IPSec logs to find where the error message is. Without an error message indicating what the issue is it is just guesswork.

whoot · 8 August 2024 21:24

Adolf,

Correct, all PSK IPSec Roadwarriors can resolve anything anywhere.

All non validating DNS servers have been disabled, and just tried a certificate based IPSec RW, and still experiences same condition of being unable to resolve ANY address, internal or external.

I am including a full dump of the charon output below of a test connection, resolving address using PSK, and then another one with a cert from start to close (this includes the PSK connection and the Cert connections. Please forgive me if there was a better way to upload this…see below.

Just strange that this would just stop working, considering we made no changes.

Aug  8 17:16:45 ******* charon: 16[NET] received packet: from yyy.yyy.yyy.yyy[49733] to xxx.xxx.xxx.xxx[500] (1096 bytes) 
Aug  8 17:16:45 ******* charon: 16[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] 
Aug  8 17:16:45 ******* charon: 16[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:16:45 ******* charon: 16[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:16:45 ******* charon: 16[CFG] selected proposal: IKE:CHACHA20_POLY1305/PRF_HMAC_SHA2_512/CURVE_448 
Aug  8 17:16:45 ******* charon: 16[IKE] remote host is behind NAT 
Aug  8 17:16:45 ******* charon: 16[IKE] DH group CURVE_25519 unacceptable, requesting CURVE_448 
Aug  8 17:16:45 ******* charon: 16[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ] 
Aug  8 17:16:45 ******* charon: 16[NET] sending packet: from xxx.xxx.xxx.xxx[500] to yyy.yyy.yyy.yyy[49733] (38 bytes) 
Aug  8 17:16:45 ******* charon: 06[NET] received packet: from yyy.yyy.yyy.yyy[49733] to xxx.xxx.xxx.xxx[500] (1120 bytes) 
Aug  8 17:16:45 ******* charon: 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] 
Aug  8 17:16:45 ******* charon: 06[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:16:45 ******* charon: 06[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:16:45 ******* charon: 06[CFG] selected proposal: IKE:CHACHA20_POLY1305/PRF_HMAC_SHA2_512/CURVE_448 
Aug  8 17:16:45 ******* charon: 06[IKE] remote host is behind NAT 
Aug  8 17:16:45 ******* charon: 06[IKE] sending cert request for "C=US, O=XXXXXX, CN=XXXXXX CA, E=*******@xxxxxxxxx" 
Aug  8 17:16:45 ******* charon: 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ] 
Aug  8 17:16:45 ******* charon: 06[NET] sending packet: from xxx.xxx.xxx.xxx[500] to yyy.yyy.yyy.yyy[49733] (285 bytes) 
Aug  8 17:16:45 ******* charon: 07[NET] received packet: from yyy.yyy.yyy.yyy[56437] to xxx.xxx.xxx.xxx[4500] (522 bytes) 
Aug  8 17:16:45 ******* charon: 07[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ AUTH CPRQ(ADDR ADDR6 DNS NBNS DNS6) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ] 
Aug  8 17:16:45 ******* charon: 07[IKE] received cert request for "C=US, O=XXXXXX, CN=XXXXXX CA, E=*******@xxxxxxxxx" 
Aug  8 17:16:45 ******* charon: 07[CFG] looking for peer configs matching xxx.xxx.xxx.xxx[%any]...yyy.yyy.yyy.yyy[192.168.64.53] 
Aug  8 17:16:45 ******* charon: 07[CFG] selected peer config 'PSKAdm' 
Aug  8 17:16:45 ******* charon: 07[IKE] authentication of '192.168.64.53' with pre-shared key successful 
Aug  8 17:16:45 ******* charon: 07[IKE] peer supports MOBIKE 
Aug  8 17:16:45 ******* charon: 07[CFG] no IDr configured, fall back on IP address 
Aug  8 17:16:45 ******* charon: 07[IKE] authentication of 'xxx.xxx.xxx.xxx' (myself) with pre-shared key 
Aug  8 17:16:45 ******* charon: 07[IKE] peer requested virtual IP %any 
Aug  8 17:16:45 ******* charon: 07[CFG] reassigning offline lease to '192.168.64.53' 
Aug  8 17:16:45 ******* charon: 07[IKE] assigning virtual IP 192.168.128.2 to peer '192.168.64.53' 
Aug  8 17:16:45 ******* charon: 07[IKE] peer requested virtual IP %any6 
Aug  8 17:16:45 ******* charon: 07[IKE] no virtual IP found for %any6 requested by '192.168.64.53' 
Aug  8 17:16:45 ******* charon: 07[IKE] IKE_SA PSKAdm[33] established between xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]...yyy.yyy.yyy.yyy[192.168.64.53] 
Aug  8 17:16:45 ******* charon: 07[IKE] IKE_SA PSKAdm[33] established between xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]...yyy.yyy.yyy.yyy[192.168.64.53] 
Aug  8 17:16:45 ******* charon: 07[IKE] scheduling reauthentication in 9807s 
Aug  8 17:16:45 ******* charon: 07[IKE] maximum IKE_SA lifetime 10347s 
Aug  8 17:16:45 ******* charon: 07[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQ 
Aug  8 17:16:45 ******* charon: 07[IKE] CHILD_SA PSKAdm{194} established with SPIs cbe9f078_i c6b7535e_o and TS 0.0.0.0/0 === 192.168.128.2/32 
Aug  8 17:16:45 ******* charon: 07[IKE] CHILD_SA PSKAdm{194} established with SPIs cbe9f078_i c6b7535e_o and TS 0.0.0.0/0 === 192.168.128.2/32 
Aug  8 17:16:45 ******* charon: 07[ENC] generating IKE_AUTH response 1 [ IDr AUTH CPRP(ADDR DNS) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ] 
Aug  8 17:16:45 ******* charon: 07[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[56437] (373 bytes) 
Aug  8 17:16:45 ******* charon: 05[NET] received packet: from yyy.yyy.yyy.yyy[56437] to xxx.xxx.xxx.xxx[4500] (81 bytes) 
Aug  8 17:16:45 ******* charon: 05[ENC] parsed INFORMATIONAL request 2 [ N(ADD_4_ADDR) N(ADD_4_ADDR) ] 
Aug  8 17:16:45 ******* charon: 05[ENC] generating INFORMATIONAL response 2 [ ] 
Aug  8 17:16:45 ******* charon: 05[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[56437] (57 bytes) 
Aug  8 17:16:55 ******* charon: 14[NET] received packet: from yyy.yyy.yyy.yyy[56437] to xxx.xxx.xxx.xxx[4500] (65 bytes) 
Aug  8 17:16:55 ******* charon: 14[ENC] parsed INFORMATIONAL request 3 [ D ] 
Aug  8 17:16:55 ******* charon: 14[IKE] received DELETE for IKE_SA PSKAdm[33] 
Aug  8 17:16:55 ******* charon: 14[IKE] deleting IKE_SA PSKAdm[33] between xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]...yyy.yyy.yyy.yyy[192.168.64.53] 
Aug  8 17:16:55 ******* charon: 14[IKE] deleting IKE_SA PSKAdm[33] between xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]...yyy.yyy.yyy.yyy[192.168.64.53] 
Aug  8 17:16:55 ******* charon: 14[IKE] IKE_SA deleted 
Aug  8 17:16:55 ******* charon: 14[IKE] IKE_SA deleted 
Aug  8 17:16:55 ******* charon: 14[ENC] generating INFORMATIONAL response 3 [ ] 
Aug  8 17:16:55 ******* charon: 14[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[56437] (57 bytes) 
Aug  8 17:16:55 ******* charon: 14[CFG] lease 192.168.128.2 by '192.168.64.53' went offline 
Aug  8 17:17:07 ******* charon: 05[NET] received packet: from yyy.yyy.yyy.yyy[60176] to xxx.xxx.xxx.xxx[500] (660 bytes) 
Aug  8 17:17:07 ******* charon: 05[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] 
Aug  8 17:17:07 ******* charon: 05[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:17:07 ******* charon: 05[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:17:07 ******* charon: 05[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_384 
Aug  8 17:17:07 ******* charon: 05[IKE] remote host is behind NAT 
Aug  8 17:17:07 ******* charon: 05[IKE] DH group MODP_2048_256 unacceptable, requesting ECP_384 
Aug  8 17:17:07 ******* charon: 05[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ] 
Aug  8 17:17:07 ******* charon: 05[NET] sending packet: from xxx.xxx.xxx.xxx[500] to yyy.yyy.yyy.yyy[60176] (38 bytes) 
Aug  8 17:17:07 ******* charon: 10[NET] received packet: from yyy.yyy.yyy.yyy[60176] to xxx.xxx.xxx.xxx[500] (500 bytes) 
Aug  8 17:17:07 ******* charon: 10[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] 
Aug  8 17:17:07 ******* charon: 10[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:17:07 ******* charon: 10[IKE] yyy.yyy.yyy.yyy is initiating an IKE_SA 
Aug  8 17:17:07 ******* charon: 10[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_384 
Aug  8 17:17:07 ******* charon: 10[IKE] remote host is behind NAT 
Aug  8 17:17:07 ******* charon: 10[IKE] sending cert request for "C=US, O=XXXXXX, CN=XXXXXX CA, E=*******@xxxxxxxxx" 
Aug  8 17:17:07 ******* charon: 10[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ] 
Aug  8 17:17:07 ******* charon: 10[NET] sending packet: from xxx.xxx.xxx.xxx[500] to yyy.yyy.yyy.yyy[60176] (329 bytes) 
Aug  8 17:17:07 ******* charon: 13[NET] received packet: from yyy.yyy.yyy.yyy[58154] to xxx.xxx.xxx.xxx[4500] (1248 bytes) 
Aug  8 17:17:07 ******* charon: 13[ENC] parsed IKE_AUTH request 1 [ EF(1/3) ] 
Aug  8 17:17:07 ******* charon: 13[ENC] received fragment #1 of 3, waiting for complete IKE message 
Aug  8 17:17:07 ******* charon: 12[NET] received packet: from yyy.yyy.yyy.yyy[58154] to xxx.xxx.xxx.xxx[4500] (1248 bytes) 
Aug  8 17:17:07 ******* charon: 12[ENC] parsed IKE_AUTH request 1 [ EF(2/3) ] 
Aug  8 17:17:07 ******* charon: 12[ENC] received fragment #2 of 3, waiting for complete IKE message 
Aug  8 17:17:07 ******* charon: 09[NET] received packet: from yyy.yyy.yyy.yyy[58154] to xxx.xxx.xxx.xxx[4500] (235 bytes) 
Aug  8 17:17:07 ******* charon: 09[ENC] parsed IKE_AUTH request 1 [ EF(3/3) ] 
Aug  8 17:17:07 ******* charon: 09[ENC] received fragment #3 of 3, reassembled fragmented IKE message (2605 bytes) 
Aug  8 17:17:07 ******* charon: 09[ENC] parsed IKE_AUTH request 1 [ IDi CERT CERTREQ AUTH CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ] 
Aug  8 17:17:07 ******* charon: 09[IKE] received cert request for "C=US, O=XXXXXX, CN=XXXXXX CA, E=*******@xxxxxxxxx" 
Aug  8 17:17:07 ******* charon: 09[IKE] received end entity cert "C=US, O=XXXXXX, CN=Palladium" 
Aug  8 17:17:07 ******* charon: 09[CFG] looking for peer configs matching xxx.xxx.xxx.xxx[%any]...yyy.yyy.yyy.yyy[C=US, O=XXXXXX, CN=Palladium] 
Aug  8 17:17:07 ******* charon: 09[CFG] selected peer config 'Palladium' 
Aug  8 17:17:07 ******* charon: 09[CFG]   using trusted certificate "C=US, O=XXXXXX, CN=Palladium" 
Aug  8 17:17:07 ******* charon: 09[CFG]   using trusted ca certificate "C=US, O=XXXXXX, CN=XXXXXX CA, E=*******@xxxxxxxxx" 
Aug  8 17:17:07 ******* charon: 09[CFG]   reached self-signed root ca with a path length of 0 
Aug  8 17:17:07 ******* charon: 09[CFG] checking certificate status of "C=US, O=XXXXXX, CN=Palladium" 
Aug  8 17:17:07 ******* charon: 09[CFG] certificate status is not available 
Aug  8 17:17:07 ******* charon: 09[IKE] authentication of 'C=US, O=XXXXXX, CN=Palladium' with RSA_EMSA_PKCS1_SHA2_384 successful 
Aug  8 17:17:07 ******* charon: 09[IKE] peer supports MOBIKE 
Aug  8 17:17:07 ******* charon: 09[IKE] authentication of 'C=US, O=XXXXXX, CN=*******.xxxxxxxxx' (myself) with RSA_EMSA_PKCS1_SHA2_384 successful 
Aug  8 17:17:07 ******* charon: 09[IKE] sending end entity cert "C=US, O=XXXXXX, CN=*******.xxxxxxxxx" 
Aug  8 17:17:07 ******* charon: 09[IKE] peer requested virtual IP %any 
Aug  8 17:17:07 ******* charon: 09[CFG] reassigning offline lease to 'C=US, O=XXXXXX, CN=Palladium' 
Aug  8 17:17:07 ******* charon: 09[IKE] assigning virtual IP 192.168.128.1 to peer 'C=US, O=XXXXXX, CN=Palladium' 
Aug  8 17:17:07 ******* charon: 09[IKE] IKE_SA Palladium[35] established between xxx.xxx.xxx.xxx[C=US, O=XXXXXX, CN=*******.xxxxxxxxx]...yyy.yyy.yyy.yyy[C=US, O=XXXXXX, CN=Palladium] 
Aug  8 17:17:07 ******* charon: 09[IKE] IKE_SA Palladium[35] established between xxx.xxx.xxx.xxx[C=US, O=XXXXXX, CN=*******.xxxxxxxxx]...yyy.yyy.yyy.yyy[C=US, O=XXXXXX, CN=Palladium] 
Aug  8 17:17:07 ******* charon: 09[IKE] scheduling reauthentication in 42614s 
Aug  8 17:17:07 ******* charon: 09[IKE] maximum IKE_SA lifetime 43154s 
Aug  8 17:17:07 ******* charon: 09[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ 
Aug  8 17:17:07 ******* charon: 09[IKE] CHILD_SA Palladium{195} established with SPIs ce958887_i ced23074_o and TS 0.0.0.0/0 === 192.168.128.1/32 
Aug  8 17:17:07 ******* charon: 09[IKE] CHILD_SA Palladium{195} established with SPIs ce958887_i ced23074_o and TS 0.0.0.0/0 === 192.168.128.1/32 
Aug  8 17:17:07 ******* charon: 09[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH CPRP(ADDR DNS DNS) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ] 
Aug  8 17:17:07 ******* charon: 09[ENC] splitting IKE message (2650 bytes) into 3 fragments 
Aug  8 17:17:07 ******* charon: 09[ENC] generating IKE_AUTH response 1 [ EF(1/3) ] 
Aug  8 17:17:07 ******* charon: 09[ENC] generating IKE_AUTH response 1 [ EF(2/3) ] 
Aug  8 17:17:07 ******* charon: 09[ENC] generating IKE_AUTH response 1 [ EF(3/3) ] 
Aug  8 17:17:07 ******* charon: 09[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[58154] (1248 bytes) 
Aug  8 17:17:07 ******* charon: 09[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[58154] (1248 bytes) 
Aug  8 17:17:07 ******* charon: 09[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[58154] (280 bytes) 
Aug  8 17:17:08 ******* charon: 14[NET] received packet: from yyy.yyy.yyy.yyy[58154] to xxx.xxx.xxx.xxx[4500] (113 bytes) 
Aug  8 17:17:08 ******* charon: 14[ENC] parsed INFORMATIONAL request 2 [ N(NATD_S_IP) N(NATD_D_IP) ] 
Aug  8 17:17:08 ******* charon: 14[ENC] generating INFORMATIONAL response 2 [ N(NATD_S_IP) N(NATD_D_IP) ] 
Aug  8 17:17:08 ******* charon: 14[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[58154] (113 bytes) 
Aug  8 17:17:15 ******* charon: 10[NET] received packet: from yyy.yyy.yyy.yyy[58154] to xxx.xxx.xxx.xxx[4500] (65 bytes) 
Aug  8 17:17:15 ******* charon: 10[ENC] parsed INFORMATIONAL request 3 [ D ] 
Aug  8 17:17:15 ******* charon: 10[IKE] received DELETE for IKE_SA Palladium[35] 
Aug  8 17:17:15 ******* charon: 10[IKE] deleting IKE_SA Palladium[35] between xxx.xxx.xxx.xxx[C=US, O=XXXXXX, CN=*******.xxxxxxxxx]...yyy.yyy.yyy.yyy[C=US, O=XXXXXX, CN=Palladium] 
Aug  8 17:17:15 ******* charon: 10[IKE] deleting IKE_SA Palladium[35] between xxx.xxx.xxx.xxx[C=US, O=XXXXXX, CN=*******.xxxxxxxxx]...yyy.yyy.yyy.yyy[C=US, O=XXXXXX, CN=Palladium] 
Aug  8 17:17:15 ******* charon: 10[IKE] IKE_SA deleted 
Aug  8 17:17:15 ******* charon: 10[IKE] IKE_SA deleted 
Aug  8 17:17:15 ******* charon: 10[ENC] generating INFORMATIONAL response 3 [ ] 
Aug  8 17:17:15 ******* charon: 10[NET] sending packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[58154] (57 bytes) 
Aug  8 17:17:15 ******* charon: 10[CFG] lease 192.168.128.1 by 'C=US, O=XXXXXX, CN=Palladium' went offline

bonnietwin · 8 August 2024 21:36

I couldn’t find any error messages of any sort in the logs, That suggests the issue is not related directly to the IPSec package but somewhere else.

I am not very familiar with IPSec to be able to figure out what might be causing the problem and I have run out of any further ideas of where to look.

Hopefully some other users with certificate based IPSec RW connections can give some input on things to look at to try and figure out what is causing the problem.

whoot · 8 August 2024 21:59

Thank you for your efforts Adolf. It was worth a try. Hopefully someone has an idea.

whoot · 9 August 2024 12:50

Adolf,

I happened to notice a similar conversation you had with another user in this post concerning OpenVPN recently. Login on Android Client via OPN VPN not working - #9 by ritchie

Has IPFire actually changed something? I even upgraded to version 187 this morning and am still experiencing the same problem.

What is very strange is the 12 IPFire firewalls we have running for various needs at very different geographical locations across the US are all experiencing this same behavior where the PSK version of IPSec is fully operational, whereas all Cert based IPSec connections cannot find addresses to resolve. I even created a firewall rule in hopes of forcing it, with no success

I have the Who Is Online add-on setup and am able to connect

Just no resolution anywhere, I even checked the Firewall Logs for a clue, filtering by the RW IP assigned and no evident problems are appearing…

I even went as far as to check the settings in the /var/ipfire/vpn/ipsec.conf file to ensure the certificate based connections had something similar to the working PSK based connection, and noticed no apparent differences…

A snippet output of the ipsec.conf file (including, file start, a certificate conn and the working PSK conn)

version 2

conn %default
        keyingtries=%forever

include /etc/ipsec.user.conf

conn PSK
        left=%defaultroute
        leftsubnet=0.0.0.0/0
        leftfirewall=yes
        lefthostaccess=yes
        leftsendcert=always
        right=%any
        type=tunnel
        ike=chacha20poly1305-sha2_512-curve448,chacha20poly1305-sha2_512-curve25519,chacha20poly1305-sha2_512-ecp521,chacha20poly1305-sha2_512-ec>
        esp=chacha20poly1305-sha2_512-curve448,chacha20poly1305-sha2_512-curve25519,chacha20poly1305-sha2_512-ecp521,chacha20poly1305-sha2_512-ec>
        keyexchange=ikev2
        ikelifetime=3h
        keylife=1h
        dpdaction=clear
        dpddelay=30
        dpdtimeout=120
        authby=secret
        auto=add
        rightsourceip=192.168.128.1/27
        fragmentation=yes
        rightdns=192.168.9.1

conn Palladium
        left=%defaultroute
        leftsubnet=0.0.0.0/0
        leftfirewall=yes
        lefthostaccess=yes
        leftsendcert=always
        right=%any
        leftcert=/var/ipfire/certs/hostcert.pem
        rightcert=/var/ipfire/certs/Palladiumcert.pem
        type=tunnel
        ike=chacha20poly1305-sha2_512-curve448,chacha20poly1305-sha2_512-curve25519,chacha20poly1305-sha2_512-ecp521,chacha20poly1305-sha2_512-ec>
        esp=chacha20poly1305-sha2_512-curve448,chacha20poly1305-sha2_512-curve25519,chacha20poly1305-sha2_512-ecp521,chacha20poly1305-sha2_512-ec>
        keyexchange=ikev2
        ikelifetime=12h
        keylife=4h
        dpdaction=clear
        dpddelay=30
        dpdtimeout=120
        authby=rsasig
        leftrsasigkey=%cert
        rightrsasigkey=%cert
        auto=add
        rightsourceip=192.168.128.1/27
        fragmentation=yes
        rightdns=192.168.9.1

Perhaps I am still missing something, but my experience leans towards suggesting this may be a bug within the IPFire core

bonnietwin · 9 August 2024 13:17

That is specifically for OpenVPN and not for IPSec. The file involved is not used in IPSec.

Also if you had the type of issue mentioned in that post then you would be totally unable to make a connection because the client certificate would have been revoked. You are able to make a connection but cannot then resolve any Domain Names that you are trying to access.

Also you would then have error messages about the client certificate being unusable as it was revoked. You don’t have any messages like that in your logs. You don’t have any error messages in your IPSec logs.

This confirms that the certificate is working, otherwise you would not be able to connect, so the other thread you highlighted is nothing to do with your issue. That issue was also fixed in the Core Update 187 release.

Unfortunately, I can’t help you on that as I am totally unfamiliar with the details of the IPSec conf file contents. I have only just started to experiment with IPSec on my vm testbed systems.

You need a forum user who is experienced in using IPSec to suggest what things to look at.

whoot · 13 September 2024 10:45

Hello everyone, I have figured out why Certificate Based Connections were experiencing connectivity issues; considering the many of our certificate based users were using Android systems, we discovered that many of the Androids were using the “recommended Private DNS” functionality under the Connections setting section. Once this was turned off, all DNS resolution came back and our certificates can be used again.

Not sure if this is something that could be improved in the next release of IPFire but figured we would share our discovery

dr_techno · 18 September 2024 03:42

The first error to look at is file permission and ownership. Which is the common issue with certs externally generated.

I’ll have some time tomorrow to look at your ipsec.conf in detail, but for now, nothing sticks out glancing at it.

The permissions should be either 550 or 640. Depending on the OS that generated the cert, it will be generated with 550,600,640 or 644 file permissions.