> On Jun 11, 2025, at 17:47, [email protected] wrote:
>
> Using book on OpenSwan (your book which I found very interesting) it requires
> the manual configuration of the DNS records
That’s a very old version of things. If you use a CA and certificates for each
node, you don’t need DNS records (but libreswan does allow you to enable a
check that the cert FQDN matches an A/AAAA record (after it got triggered by IP)
Also, the unbound resolver supports libreswan as module so you can run a local
DNS resolver and whenever it looks up A/AAAA it also looks up IPSECKEY records
and if found, gives the pubkey/IP to libreswan to negotiate IKE before unbound
returns the A/AAAA to the application.
So by the time the application opens a connection, it’s covered by an existing
IPsec tunnel. And it only does it for lookups for names that were not already
in the cache.
> I specifically targeted IPv6 only so that NAT would not be an issue, given
> the size of the IPv6 address space.
That might work in clouds but not with mobile networks using CGNAT.
> Internally if an organisation wanted to secure internal communication then
> the IPv6 hosts could be configured to automatically populate their public
> IPSec information into DNS via DHCP so all internal communication could use
> IPSec Tunnel mode as a point to point connection.
It’s much easier to just give them all a certificate and opportunistically try
it based on CIDR networks of the internal networks.
> IPSec transport could be used internally but I would expect this to be more
> typically used within a DMZ allowing external clients to make an IPSec
> connection to a public IPv6 host,
>
You can use transport mode if you are sure that there is no NAT.
Paul
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
