IPSec Certificate Based Connections DNS Resolution Issues

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