dns on SLXH.nl

NAT64 performance

Wed, 31 Mar 2021 20:07:06 +0200

This post is an update of my previous post about NAT64. That post describes the following setup:

 IPv4 IPv4
Internet ────── Router ────── NAT64
IPv6 │ │ IPv6
└────────── Host
IPv6

This has the following components in the network:

A router that routes IPv6 and routes or NATs IPv4.
A NAT64 server that performs thanslation of IPv4 and IPv6.
A host that only has IPv6 connectivity.

The is to use the NAT64 server both ways: the NAT64 server is used for IPv4 connectivity (looking at you, GitHub), and to reach the IPv6-only hosts over IPv4.

Currently, I still use Tayga for this setup. The main downside of Tayga is it’s (low) performance. This performance is the main reason various hosts in my network still have an IPv4 address. I have also replaced my home router with a PCEngines APU, which should perform much better than the Edgerouter Lite it replaced.

Alternatives

There are various alternatives to Tayga:

OpenBSD’s PF (using af-to).
Jool can perform both (stateful) NAT64 and (stateless) SIIT.
map646 only performs stateless NAT64.

The latter two have been compared against Tayga in this paper, which found the following performance:

Solution	frame/s	Mbps (est.)
Jool	230000	2760
Tayga	120000	1440
map646	60000	720

Note that the throughput for Tayga is significantly greater than I was able to achieve in my previous post (252 Mbps). Additionally, the performance of Jool looks interesting…

Test setup

The following devices are used for testing the performance of Tayga, Jool and PF:

	PCEngines APU	Ryzen 2600X	Ryzen 4650G
CPU	AMD GX-412	AMD Ryzen 5 2600X	AMD Ryzen 5 PRO 4650G
NIC	Intel i211AT	Intel X550-T2	Mellanox ConnectX-3 EN
RAM	2GB DDR3-1333	32GB DDR4-3200	32GB DDR4-3200

Both the PCEngines APU and the Ryzen2600X are used as NAT64 device, while the Ryzen 4650G is used to measure performance.

Fresh installations of OpenBSD 6.8 and Debian Bullseye are used for the tests. No performance tuning is done.

Tests are performed using iPerf3 using a single TCP flow on a single link (in full duplex). The best of three measurements is used as the result.

A few notes:

Note that these numbers do not include overhead from Ethernet, IP or TCP (5-6%).
The network, and the devices, may be somewhat in use.
Only a single full-duplex link is used.

This means that the results below should be taken with a grain of salt.

Different types of NAT

Tayga, Jool and PF work differently:

Tayga and PF (and Jool in NAT64 mode) masquerade the original IP. Tayga can do so using an (optional) dynamic pool, and static mappings.
PF also masquerades the IPv6 address in the NAT46 flow.
Jool (in SIIT mode) does a stateless translation between IPs. This means that the original IP also has to be one from the pool.
Jool (in SIIT mode) translates all IPv4 traffic.

Example translations for NAT64:

	Orig From	Orig To	NAT From	NAT To
Tayga	*	64:ff9b::10.64.0.10	10.64.0.0/24	10.64.0.10
Jool	64:ff9b::10.64.1.10	64:ff9b::10.64.0.10	10.64.1.10	10.64.0.10
PF	*	64:ff9b::10.64.0.10	10.64.0.1	10.64.0.10

Example translations for NAT46:

	Orig From	Orig To	NAT From	NAT To
Tayga	10.64.1.10	10.64.0.10	2001:db8::10.64.1.10	2001:db8::10.64.0.10
Jool	10.64.1.10	10.64.0.10	2001:db8::10.64.1.10	2001:db8::10.64.0.10
PF	*	10.64.0.10	2001:db8::1	2001:db8::10.64.0.10

Results

Performance on the PCEngines APU in Mbps:

	IPv4	IPv6	NAT64	NAT46
Tayga	903	887	199	197
Jool	-	869	805	825
PF	646	488	572	444

Performance on the Ryzen 2600X in Mbps:

	IPv4	IPv6	NAT64	NAT46
Tayga	8478	8361	2971	2807
Jool	-	7819	8193	8091
PF	6292	5006	2354	5440

As a bonus: performance of Jool in a container on the Ryzen 4650G in Mbps:

	IPv4	IPv6	NAT64	NAT46
Jool	15216	14406	14426	10097

This means the performance of the solutions, when compared to the line rate, is as follows:

Solution	Platform	NAT64	NAT46
Tayga	PCEngines APU	21%	21%
Tayga	Ryzen 2600X	31%	29%
PF	PCEngines APU	50%	47%
PF	Ryzen 2600X	25%	58%
Jool	PCEngines APU	85%	88%
Jool	Ryzen 2600X	88%	86%

Conclusion

While Tayga claims that it “can saturate gigabit Ethernet on modest PC hardware”, this is clearly not the case for the ‘modest’ PCEngines APU. However, on a modern desktop CPU all solutions were able to attain performance exceeding 1 Gbps.

The clear winner in terms of performance is Jool, which is able to achieve almost 90% line rate on both platforms.

PGP and DNS

Thu, 22 Dec 2016 17:33:07 +0100

Recently, I looked at all the ways GnuPG can retrieve PGP keys from the internet to see which of these methods are actually useful. This blog post describes a summary of my conclusions.

GnuPG modern (2.1.16) can retrieve keys from the internet using the following mechanisms:

cert: a DNS CERT PGP record as defined in RFC-4398
pka: a DNS CERT IPGP record, also defined in RFC-4398 or a DNS TXT record, depending on the version of GnuPG. This uses an HTTP request to a location defined in the record to retrieve the key.
dane: a DNS OPENPGPKEY record, as defined in RFC-7929.
wkd: via an HTTP GET to a file in the .well-known (RFC-5785) directory. This is experimental and defined in a RFC draft.
keyserver: The common way to retrieve keys via keyservers.

So next to the common way to retrieve keys (which I will not discuss) there are four other mechanisms: two fully relying on DNS, one using a mix of DNS and HTTP(S) and one only using HTTP(S).

For testing the DNS records I used a PowerDNS (4.0.1) server on a DNSSEC signed domain (which I recommend). Note that DNSSEC is not required (not even for the DANE mechanism).

CERT record

The CERT record is quite straightforward: it is a data record in which one can place the base64 encoded information for a public key. This data (which I will call [DATA]) can be generated with:

gpg --export-options export-minimal --export F4DFA1D665C135D6 | base64 -w0

Which results in the same data as what is contained in an ASCII-armored key (except for line endings), which is formatted like:

-----BEGIN PGP PUBLIC KEY BLOCK-----
[DATA]
=[checksum]
-----END PGP PUBLIC KEY BLOCK-----

The DNS record for the identity asdf at slxh.eu looks like any the following:

asdf.slxh.eu. 86400 IN CERT PGP 0 0 [DATA]

Where PGP can be replaced by the number 3. This is required for PowerDNS.

The record is quite straight forward and it works, but only for a single key:

$ gpg2 -v --auto-key-locate=clear,cert,local --locate-keys <address>
...
gpg: auto-key-locate found fingerprint 646B0F089DD5022CF5BA29F9F4DFA1D665C135D6
gpg: automatically retrieved '<address>' via DNS CERT

Pros:

Easy to set up

Cons:

Large record which needs to be transferred over TCP
Not located at a nice place in the DNS
Only retrieves public keys from a single record (but a single record can contain multiple keys)

DANE: OPENPGP record

The dane mechanism works in a similar way to CERT, but it uses a well-defined location. The record looks like (see the CERT section for generating [DATA]):

7a5b775b45836845e91cb23b59ed7ff45d1732c7aa8415952beeb7d2._openpgpkey.slxh.eu 86400 IN OPENPGPKEY [DATA]

The compatibility format can also be generated by gpg2:

gpg --export-options export-dane --export F4DFA1D665C135D6

Which results in:

$ORIGIN _openpgpkey.slxh.eu.
7a5b775b45836845e91cb23b59ed7ff45d1732c7aa8415952beeb7d2 TYPE61 \# 1695 (
98330457e504ee16092b06010401da470f01010740752c0c3aa3bf6841a33076
...
34d3c8c4f8aaa94f53e10daff07633d2a3eea38dbd409d44d9600d9a755a0e
)

Pros:

Easy to setup with software that accepts the output of gpg2
Well defined location

Cons:

Large record which needs to be transferred over TCP
Only retrieves public keys from a single record (but a single record can contain multiple keys)

PKA: Public Key Association

The PKA record in GnuPG 2.1.16 uses the CERT IPGP record to store the fingerprint of the public key and a location where the key can be retrieved. The record has its own location and local part of the email address is hashed. There is also a TXT variant, but GnuPG does not use this for lookups any more.

GnuPG also has options for automatically doing lookups and increasing trust if the fingerprint matches on verification:

--verify-options parameters
...
pka-lookups
Enable PKA lookups to verify sender addresses. Note that PKA is based on DNS, and
so enabling this option may disclose information on when and what signatures are
verified or to whom data is encrypted. This is similar to the "web bug" described
for the --auto-key-retrieve option.
pka-trust-increase
Raise the trust in a signature to full if the signature passes PKA validation.
This option is only meaningful if pka-lookups is set.

GnuPG can also create the DNS record for you:

gpg --export-options export-pka --export F4DFA1D665C135D6

Which shows the required records for zone files:

$ORIGIN _pka.slxh.eu
yyjm39f54qomwmcejnmojaspwa86esqj TYPE37 \# 26 0006 0000 00 14 646B0F089DD5022CF5BA29F9F4DFA1D665C135D6

This output, however, is only for compatibility purposes and does not contain a URL for key retrieval.

The actual format can be generated from this information (I have made a script that does just that). The regular record looks like:

yyjm39f54qomwmcejnmojaspwa86esqj._pka.slxh.eu 3600 IN CERT 6 0 0 FGRrDwid1QIs9bop+fTfodZlwTXW

With a provided URL, in this case https://slxh.eu/keys/pgp/65C135D6, it becomes:

yyjm39f54qomwmcejnmojaspwa86esqj._pka.slxh.eu 3600 IN CERT 6 0 0 FGRrDwid1QIs9bop+fTfodZlwTXWaHR0cHM6Ly9zbHhoLmV1L2tleXMvcGdwLzY1QzEzNUQ2

The 6 may be replaced with IPGP.

The lookup of the fingerprint works. The retrieval of the key, however, does not: instead of using the provided URL it asks the server for a key with a specific URL (a PKS lookup), resulting in a Page Not Found error. This means that gpg does use the server specified in the record but ignores the URL, resulting in gpg claiming there are no keys to be retrieved. A solution to this is to simply use a keyserver (like https://sks-keyservers.net) in the record.

In my opinion this record is most useful for simply verifying the fingerprint, in which case the URL is not needed.

Pros:

Easy to setup with software that accepts the output of gpg2
Can automatically improve trust
Small DNS record
Well defined location

Cons

Does not retrieve the key from the specified location but from a keyserver instead.
Only retrieves the key for a single record

WKD: Web Key Directory

The Web Key Directory mechanism leverages the .well-known directory to store keys. Exporting to this location is relatively easy:

$ gpg2 --with-wkd-hash -k F4DFA1D665C135D6
pub ed25519/F4DFA1D665C135D6 2016-09-23 [SC] [expires: 2018-09-23]
646B0F089DD5022CF5BA29F9F4DFA1D665C135D6
uid [ full ] ...
yyjm39f54qomwmcejnmojaspwa86esqj@slxh.eu
...
$ gpg --export F4DFA1D665C135D6 > yyjm39f54qomwmcejnmojaspwa86esqj

Note that the key cannot be ASCII-armored.

The created file (yyjm39f54qomwmcejnmojaspwa86esqj) then needs to be placed on the webserver for slxh.eu, so that it is accessible at: https://slxh.eu/.well-known/openpgpkey/hu/yyjm39f54qomwmcejnmojaspwa86esqj

The export can contain multiple public keys, but in that case gpg2 will throw an error (No fingerprint) while still importing the keys. Also: only the identities for which a lookup was done are imported.

Pros:

Easy to setup
No cumbersome DNS record
Well defined location

Cons

Only retrieves the identity for which a lookup was done

Conclusion

All of the provided methods have drawbacks. Here is what I recommend:

Primarily use WKD, it is easy to maintain and works the best. Additional security can be provided by using DNSSEC and HTTPS (and DANE/TLSA).
Use OPENPGPKEY over CERT PGP. OPENPGPKEY does everything that CERT PGP does, but better. Security is provided by DNSSEC.
Use PKA only for storing fingerprints. Using it when verifying keys might be useful.

Update 2017-02-16

GnuPG 2.1.18 added a DNS lookup to WKD via a SRV record. The given example is:

_openpgpkey._tcp IN SRV 0 0 0 wkd.foo.org.
IN SRV 0 0 0 wkd.example.net.
IN SRV 0 0 4711 wkd.example.org.

Which would fetch from:

https://wkd.example.org:4711/.well-known/openpgpkey/submission-address

Explained as follows:

Note that the first two SRV records won’t be used because foo.org and example.net do not match example.org. We require that the target host is identical to the domain or be a subdomain of it. This is so that an attacker modifying the SRV records needs to setup a server in a sub-domain of the actual domain and can’t use an arbitrary domain. Whether this is a sufficient requirement is not clear and needs further discussion.

These changes add some flexibility to WKD lookups. The requirement to have the server as subdomain makes sense, but note that when an attacker has full control of the DNS this is circumvented without much hassle.

NAT64 for servers

Wed, 23 Nov 2016 16:06:17 +0100

This post details the setup of the additional steps required to deploy a IPv6-only server bedind NAT64 with Tayga.

This post uses the documentation prefix (2001:db8::/32), replace this with your own prefix. This can be a ULA prefix.

The basis is explained in a post by Luuk Hendriks.

Goal

The goal is to reach an IPv6-only webserver behind a dual stack router. This is done by using NAT64 on a third device to reach the server.

 IPv4 IPv4
Internet ────── Router ────── Tayga
IPv6 │ │ IPv6
└────────── Server
IPv6

In this case, the Router is an Edgerouter Lite and the Tayga and webserver are running on the same physical device in separate LXC containers.

Unbound

The main difference in the setup is that I use Unbound instead of PowerDNS. The configuration is really simple, in /etc/unbound/unbound.conf.d/dns64.conf:

server:
module-config: "dns64 validator iterator"
dns64-prefix: 2001:db8:64::/96

Tayga

For the two-way NAT, the Tayga configuration requires static-mappings:

# Main config
tun-device nat64
prefix 2001:db8:64::/96
ipv4-addr 10.64.0.1
dynamic-pool 10.64.0.0/24
data-dir /var/spool/tayga
# Static mappings
map 10.64.0.10 2001:db8::10 # Server 1
map 10.64.0.11 2001:db8::11 # Server 2

I have used a subnet (2001:db8:64::/96) above as prefix. This allow access to local (RFC1918) IPv4 addresses through NAT64. If this is not needed, use the Well-Known Prefix: 64:ff9b::/96.

The mapping is simple: create an IPv4 address inside the dynamic pool and map that to the IPv6 address that needs to be reached.

Route

In a regular setup, the IPv4 range is only required internally on the host running Tayga. For this setup, however, the 10.64.0.0/24 range needs to be routed to the device running Tayga.

Just like the linked post, I use an Edgerouter. The following route needs to be added:

set protocols static route 10.64.0.0/24 next-hop 10.0.0.64 distance 1

Where 10.0.0.64 is the IPv4 address of the device running Tayga.

After this route is setup, it should be possible to ping the devices mapped in Tayga.

Port forwards

If the mappings work, it should now be possible to forward ports to the mapped addresses. For a webserver this would be:

edit port-forward rule 10
set description "HTTP(S)"
set forward-to address 10.64.0.10
set original-port 80,443
set protocol tcp

If everything went well the webserver should now be reachable from the IPv4-WAN address, while only having an IPv6 address.

Final notes

I have not noticed any drawbacks to this setup except for performance. The results of some measurements from a computer in my network to the server show that the NAT transition has a performance of about 250 Mbps.

From	To	(Mbps)
	IPv4	IPv6
IPv4	927	252
IPv6	199	918

This means that the main bottleneck is the performance of Tayga, though this only matters with internet connections faster than 250 Mbps.

X.509 IPsec on EdgeOS

Thu, 31 Dec 2015 13:13:50 +0100

Configuring X.509 based IPsec on an Edgerouter running EdgeOS.

Preparation

Create a directory in /config for persistent storage of the certificates. Eg:

mkdir /config/ipsec
cd /config/ipsec

Generation of Certificates

For IPsec to work reliably, you need three certificate files:

CA-certificate: ca.crt, obtain this from your CA.
Server certificate: server.crt
Server private key: server.key

Running a CA is outside of the scope of this document, though a script (/usr/lib/ssl/misc/CA.sh) is provided to make it very easy. There are other blog posts documenting this. Personally, I prefer to use the openssl commands directly. I also advise to run the following as root (sudo -i).

First, generate a certificate signing request (CSR) for the CA to sign, replace the subject with your own values:

openssl req -new -newkey 4096 -nodes -out server.csr \
-keyout server.pem \
-subj "/C=NL/ST=/L=/O=SLXH/CN=ipsec.slxh.nl"

This private key needs to be converted to a RSA private key for the IPsec daemon on EdgeOS:

openssl rsa -in server.pem -out server.key

Change the permissions on the files:

chmod u=r,go= server.pem server.key
chown root: server.pem server.key

This CSR can now be signed by your CA. After you get the signed certificate, place in next to the private keys.

IPsec on EdgeOS

Follow the instructions provided by Ubiquiti or the ones found on their forum, with the following exceptions:

set vpn l2tp remote-access ipsec-settings authentication mode x509
set vpn l2tp remote-access ipsec-settings authentication x509 ca-cert-file /config/ipsec/ca.crt
set vpn l2tp remote-access ipsec-settings authentication x509 server-cert-file /config/ipsec/server.crt
set vpn l2tp remote-access ipsec-settings authentication x509 server-key-file /config/ipsec/server.key

Adding a certificate revocation list (CRL) is optional, but advised:

set vpn l2tp remote-access ipsec-settings authentication x509 crl-file /config/ipsec/ca.crl

Commit and save:

commit
save

Firewall

Again, follow the instructions provided by Ubiquiti. It can also be configured in the CLI (check the rule numbers first):

edit firewall name WAN_LOCAL rule 23
set action accept
set description "L2TP/IPsec"
set destination port isakmp,l2f,4500
set protocol udp
exit
edit firewall name WAN_LOCAL rule 24
set action accept
set description "ESP (IPsec)"
set protocol esp
commit
save

IPsec should now be working.