Long-term Memory » NAT http://blog.dest-unreach.be A collection of note-to-self's Sun, 29 Jan 2012 16:05:00 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Converting a WRT320N to dd-wrt http://blog.dest-unreach.be/2010/11/30/converting-a-wrt320n-to-dd-wrt http://blog.dest-unreach.be/2010/11/30/converting-a-wrt320n-to-dd-wrt#comments Tue, 30 Nov 2010 17:53:50 +0000 Niobos http://blog.dest-unreach.be/?p=1891 I bought myself a new WiFi router. When in the shop, I specifically searched for a router that is supported by dd-wrt, and has (at least) 8MB of flash. I settled for the Linksys WRT320N: it has a dual band (switchable between 2.4GHz and 5GHz, not simultaneous) 802.11a/b/g/n radio, a 4 port GbE switch, and a WAN port. It houses a Broadcom BC4717 processor running at 354MHz, 8MB of flash and 32MB of RAM.

The default Linksys firmware is actually not bad, but dd-wrt just offers a ton more features: Multiple SSIDs, IPv6 support (including Sixxs tunneling), WAN volume monitoring, custom firewalling, traffic shaping, … So I decided to void my warranty and put my router on steroids! Mandatory note: this may very well turn your router in to a very expensive brick.

The initial flash

After reading through the dd-wrt forum (most notably these three posts) and the wiki page, I learned a few things:

  • Apparently, this router has its reset button wired to the wrong GPIO pin. Therefor, the 30/30/30 reset DOES NOT WORK on this router! There is an alternative: use at least version 13493, power down the router, push and hold the WPS button (on top), power up the router, hold the WPS button for 10-12 more seconds, then release.
  • The latest recommended firmware is BrainSlayer’s 14929

This is the procedure I followed, with success, starting from Linksys version v1.0.03 (build 010Jul 24, 2009):

  1. Download the tailored build for the WRT320N (for the freaks, my binary MD5s to e1d7edd368bf5259c18a0874c5e761db).
  2. Connect via wired ethernet to the router. That way, you can see the link going up/down.
  3. In the Linksys firmware, upload this file.
  4. Wait 5 very long minutes.
  5. Configure yourself a static IP in the 192.168.0.0/24 network (I use 192.168.0.8)
  6. Direct your browser to http://192.168.0.1/
  7. Set a temporary password
  8. Wait 1 minute
  9. Reset the router: Power down, push & hold WPS button, power up, keep holding for 11 seconds, release.
  10. Close & reopen your browser to flush all cached pages and credentials
  11. Direct your browser to http://192.168.0.1/
  12. Enjoy

The upgrade

After the initial flash, you can upgrade to any regular version, but keep in mind that this unit requires a 2.6 kernel. I choose the 14929-mini version (md5 af9ab2ff822ab69d26fa7308d47ad05a), not because it provided all I need (it doesn’t support IPv6 for example), but because it leaves the most free space for me to fiddle with.

To switch versions, I always follow this overly cautious procedure:

  1. Reset to defaults: power down, push & hold WPS button, power up, keep holding for 11 seconds, release
  2. Make sure your IP is in the correct range (192.168.0.0/24)
  3. Set a temporary password
  4. Upload the new firmware
  5. Wait until the browser is again at the “Set password” page
  6. Set temporary password
  7. Reset to defaults again

The settings

Most configuration is fairly straightforward with the GUI. But setting up a second, routed SSID needed a little non-intuitive work:

  • Go to Wireless -> Basic Settings and add a new Virtual Interface
    • Leave Network Configuration to Bridged
  • Go to Setup -> Networking
    • Under Create Bridge, click Add
    • Name the new bridge “br1″ and disable STP
    • Apply Settings
    • Now add the desired IP and Subnet mask for this brigde-port
    • Apply Settings again
    • Click Add under Assign to bridge
    • Now assign the wl0.1 interface to this newly created bridge br1
  • Optionally Add a DHCP range for br1. In this case, you need to use DNSmasq as DHCP-server.

Some guides tell you to configure it in Unbridged mode. Using Bridged mode gives the potential advantage that you can link a wired port to this IP-range easily.

Now you can easily firewall between the two WLANs by putting iptables-lines in the startup script.

]]> http://blog.dest-unreach.be/2010/11/30/converting-a-wrt320n-to-dd-wrt/feed 0 DNS(SEC) – Firewall issues http://blog.dest-unreach.be/2010/02/10/dnssec-firewall-issues http://blog.dest-unreach.be/2010/02/10/dnssec-firewall-issues#comments Wed, 10 Feb 2010 18:03:25 +0000 Niobos http://blog.dest-unreach.be/?p=1630 I just read this message by Mark Andrews on the BIND mailing list. It explains the possible issues with DNSSEC and over-protective firewalls, giving test-commands to verify your setup. This post is also interesting for regular DNS traffic, since a firewall doesn’t know the difference.

Here is the most interesting part:

First, you should verify that you can talk to L.ROOT-SERVERS.NET using plain DNS. This will ensure that failures in the subsequent tests are meaningful.

e.g.

dig +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39974
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f

;; Query time: 189 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:05:49 2010
;; MSG SIZE  rcvd: 492

Next we will see whether you can receive an answer that is greater than 512 bytes. This test simulates how named makes its initial queries. Most signed responses fit between 512 bytes and 1500 bytes and are returned in a single un-fragmented UDP packet. This test is designed to check this case.

e.g.

dig +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 381
;; flags: qr aa; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 191 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 12:51:28 2010
;; MSG SIZE  rcvd: 801

If you get a response like this then your firewall passes UDP responses greater than 512 bytes.

If you did not get a response like this, you need to fix your firewall.

Next we will test to see whether you can get a response greater than 1500 bytes. Such responses are normally fragmented, and this test will find out whether your firewall will pass fragmented UDP packets. Failure to pass such responses will force named to fall back to using queries which are likely to trigger the use of TCP, which should be avoided. Failure to pass such answers will also slow up the resolution process.

e.g.

dig +dnssec +norec +ignore any . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +ignore any . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57084
;; flags: qr aa; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	ANY

;; ANSWER SECTION:
.			86400	IN	NSEC	ac. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20100214000000 20100206230000 23763 . haTtgLwOQ9Bm2F9BRqMtAzahIuUWrjcmRjFGI5s5jGUVpjgq/MOl7wRi IJ1nLQkXThzc8hn6b3faXXIhHE/8MShzOG4wFbHwJyltx8IT9E8XP4P5 Fz9TuE3EEElNE6GZNAg8UM4r8hyv/PSM8e7offdh7pg32kfW6fgoLsHy 8yQ=
.			86400	IN	DNSKEY	256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.			86400	IN	DNSKEY	257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=
.			86400	IN	RRSIG	DNSKEY 8 0 86400 20100214235959 20100131000000 19324 . v2DVoP16w3dqsOooCxAb393ExF6p1t3d3qJsYPkeV96/t3HIuVLnxpbV 02Wx+BR7dwLiURASmebvEhZrR4gNqO15M5gerrzDdY0IXA0q0xVAUj/J NvkdiniXjoQYGUwjJsdfqxvD7NQPtSz4YTuOvMlVffV1F2Bc6Woid7AK JGkb24MeQlAMy/gQqcLPs6c3a9RvZEwofMul66bUswGS+YsL8x9A6Cbt 1bdyhRUNYSl7AifA4++Pu+0MLpbrxH7DLI8O9ZfCA3LsEQUOFjYA+2jJ mzgFqZAU0HvxeQyStnLF3/bf7qifRegrn6+cTKjKtUZ52/kUFiaqgT2t 9TemTg==
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2010020701 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20100214000000 20100206230000 23763 . KA46XFSIJT3xKdvlo2av5FmeFl5R8etArvA9PLJb4JUz2jioqYTjhDbT 6L5kJQaiavMF1Lic5spulaHlCHmVy+gLetI49Nc8htnd0QPWTn/MG3do isDlv9nh6uCR6cJj5W/anIkubiLHBmO11QLwVNa1IybTgTCKHNwefxG0 i/M=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 191 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:15:19 2010
;; MSG SIZE  rcvd: 1906

If you get a reponse like this then your firewall passes UDP responses greater than 1500 bytes.

If you did not get a response like this, you need to fix your firewall.

Next we need to see whether your firewall passes outbound TCP queries. Even when using EDNS, some answers will not fit into a UDP packet. Such responses require queries to be performed over TCP.

e.g.

dig +dnssec +norec +vc any . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +vc any . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20036
;; flags: qr aa; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	ANY

;; ANSWER SECTION:
.			86400	IN	NSEC	ac. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20100214000000 20100206230000 23763 . haTtgLwOQ9Bm2F9BRqMtAzahIuUWrjcmRjFGI5s5jGUVpjgq/MOl7wRi IJ1nLQkXThzc8hn6b3faXXIhHE/8MShzOG4wFbHwJyltx8IT9E8XP4P5 Fz9TuE3EEElNE6GZNAg8UM4r8hyv/PSM8e7offdh7pg32kfW6fgoLsHy 8yQ=
.			86400	IN	DNSKEY	256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.			86400	IN	DNSKEY	257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=
.			86400	IN	RRSIG	DNSKEY 8 0 86400 20100214235959 20100131000000 19324 . v2DVoP16w3dqsOooCxAb393ExF6p1t3d3qJsYPkeV96/t3HIuVLnxpbV 02Wx+BR7dwLiURASmebvEhZrR4gNqO15M5gerrzDdY0IXA0q0xVAUj/J NvkdiniXjoQYGUwjJsdfqxvD7NQPtSz4YTuOvMlVffV1F2Bc6Woid7AK JGkb24MeQlAMy/gQqcLPs6c3a9RvZEwofMul66bUswGS+YsL8x9A6Cbt 1bdyhRUNYSl7AifA4++Pu+0MLpbrxH7DLI8O9ZfCA3LsEQUOFjYA+2jJ mzgFqZAU0HvxeQyStnLF3/bf7qifRegrn6+cTKjKtUZ52/kUFiaqgT2t 9TemTg==
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2010020701 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20100214000000 20100206230000 23763 . KA46XFSIJT3xKdvlo2av5FmeFl5R8etArvA9PLJb4JUz2jioqYTjhDbT 6L5kJQaiavMF1Lic5spulaHlCHmVy+gLetI49Nc8htnd0QPWTn/MG3do isDlv9nh6uCR6cJj5W/anIkubiLHBmO11QLwVNa1IybTgTCKHNwefxG0 i/M=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 380 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:18:19 2010
;; MSG SIZE  rcvd: 1906

If you did not receive a answer like this, you need to fix your firewall.

If all the above tests succeeded, then you should have no issues when all the root servers are responding with signed versions of the root zone.

]]> http://blog.dest-unreach.be/2010/02/10/dnssec-firewall-issues/feed 0 The journey of an IP packet through a Linux iptables firewall http://blog.dest-unreach.be/2009/04/22/the-journey-of-an-ip-packet-through-a-linux-iptables-firewall http://blog.dest-unreach.be/2009/04/22/the-journey-of-an-ip-packet-through-a-linux-iptables-firewall#comments Wed, 22 Apr 2009 17:30:22 +0000 Niobos http://blog.dest-unreach.be/?p=1082 When doing some research on the different tables in iptables, I was trying to figure out in what order what tables are traversed. Obviously PREROUTING happens before POSTROUTING, but it becomes more difficult to figure out if mangle happens before are after nat.

I found a post which links to this overview:

packetflow

]]> http://blog.dest-unreach.be/2009/04/22/the-journey-of-an-ip-packet-through-a-linux-iptables-firewall/feed 0 IPv6 in the home network http://blog.dest-unreach.be/2009/03/17/ipv6-in-the-home-network http://blog.dest-unreach.be/2009/03/17/ipv6-in-the-home-network#comments Tue, 17 Mar 2009 18:59:26 +0000 Niobos http://blog.dest-unreach.be/?p=916 IPv6 is, big surprise, the new version of IP. The current internet runs on IPv4, which has some drawbacks. Practically both versions are the same: they allow connections from one host to another host. Technically however, there are some major differences, most notably the enlarged address space. For the moment, most hosts will run a dual-stack configuration.

I decided that it was time to implement IPv6 on my home network and get a IPv6 connection to the IPv6-Internet.

Getting IPv6 to work wasn’t difficult at all. All it took was to configure an address on my Linux-based router/firewall:

# ip -6 addr add dev eth0 2001:db8:1:2:1122:33ff:fe44:5566/64

I used EUI-64 type addresses to be consistent with the rest of the network, but you can choose freely. Note that the examples use IPv6 addresses reserved for documentation, don’t use these addresses!

Next, I configured radvd, the router advertisement daemon:

# /etc/radvd.conf

interface eth0 {
	AdvSendAdvert on;
	MaxRtrAdvInterval 600;
	AdvManagedFlag off;
	AdvOtherConfigFlag off;
	prefix 2001:db8:1:2::/64 {
		AdvAutonomous on;
		AdvValidLifetime 604800;
		AdvPreferredLifetime 86400;
	};
	RDNSS 2001:db8:1:2:1122:33ff:fe44:5566 {
	};
};

By the time I opened my System Preferences, my Mac had already assigned itself an IPv6 address and I was able to ping the router.

The IPv6 Internet

With the above configuration, I was running an IPv6 island. There was no way to communicate with the outside world (over IPv6). Since my ISP doesn’t know what IPv6 is, I needed another way to get a connection to the IPv6 internet. Sixxs.net provides exactly this. Note that all requests are manually processed, so it can take a while to get them all approved. Mine took around 24 hours from account-request to subnet approval.

Since my router has a public IP address, I chose the heartbeat tunnel, which uses plain IPv6-in-IPv4 (sit) tunneling. My AICCU configuration looks like this:

# /etc/aiccu.conf

username -SIXXS
password 

protocol tsp
server tic.sixxs.net
ipv6_interface sit_sixxs
verbose false
daemonize true
automatic true
requiretls false

Simply starting AICCU got my tunnel up and connected me to the IPv6 Internet:

# ip addr sh
<stripped>
160: sit_sixxs@NONE: <POINTOPOINT,NOARP,UP,10000> mtu 1280 qdisc noqueue
    link/sit <stripped> peer <stripped>
    inet6 2001:<stripped>:2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::5740:191d/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::a11:ff01/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:0/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::a11:1/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::c0a8:ff01/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::a11:201/64 scope link
       valid_lft forever preferred_lft forever
<stripped>
# ping6 -n sixxs.net
PING sixxs.net(2001:838:1:1:210:dcff:fe20:7c7c) 56 data bytes
64 bytes from 2001:838:1:1:210:dcff:fe20:7c7c: icmp_seq=1 ttl=54 time=18.9 ms
64 bytes from 2001:838:1:1:210:dcff:fe20:7c7c: icmp_seq=2 ttl=54 time=18.2 ms
64 bytes from 2001:838:1:1:210:dcff:fe20:7c7c: icmp_seq=3 ttl=54 time=18.3 ms
^C
--- sixxs.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2011ms
rtt min/avg/max/mdev = 18.271/18.518/18.945/0.341 ms
#

Routed subnet

We now have IPv6 connectivity to the IPv6 internet from the router/firewall. The IPv4-way of getting that access to our internal hosts is to many-to-one-NAT all boxes behind this single public address. Since IPv6 has many more addresses, the normal way is to give each internal host its own public address. Sixxs.net also provides subnets on request, usually /48.

Once the subnet-request was approved, simply changing the IP of the firewall, changing the radvd.conf and restarting radvd was enough to get the IPv6 internet to the inside hosts. Since all hosts now have public addresses, it may be a wise choise to firewall them.

Privacy Extension

IPv6 provides a Privacy Extension feature which, surprise, enhances privacy. On MacOSX 10.5 Leopard this is disabled by default. Enabling it requires a sysctl:

# sysctl net.inet6.ip6.use_tempaddr
net.inet6.ip6.use_tempaddr: 0
# sysctl -w net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.use_tempaddr: 0 -> 1
# sysctl net.inet6.ip6.use_tempaddr
net.inet6.ip6.use_tempaddr: 1

To make these changes permanent, Mac apparently uses the standard sysctl.conf:

# /etc/sysctl.conf
# Generate and use IPv6 Privacy Extension addresses
net.inet6.ip6.use_tempaddr=1
]]> http://blog.dest-unreach.be/2009/03/17/ipv6-in-the-home-network/feed 2 Terminating an IPsec-GRE tunnel behind NAT http://blog.dest-unreach.be/2008/07/11/terminating-an-ipsec-gre-tunnel-behind-nat http://blog.dest-unreach.be/2008/07/11/terminating-an-ipsec-gre-tunnel-behind-nat#comments Fri, 11 Jul 2008 17:18:23 +0000 Niobos http://blog.dest-unreach.be/?p=82 Recently I had to configure a router serving as an IPsec-GRE endpoint. So far, nothing special. The interesting part is that the terminating router is behind a NAT-device which changes the outer IP-header of the IPsec tunnel. Of course, the GRE-header is NOT affected by the NAT (since it is encrypted).

To summarize, the device needs to:

  • terminate an IPsec tunnel between 172.16.2.2 <-> 10.0.0.4 (its own IP); but authenticate as 172.16.2.4
  • terminate a GRE tunnel between 172.16.1.1 <-> 172.16.2.4 (a public IP that is NATed towards it)

The diagram is shown below:

172.16.x.x addresses are “public”; 10.x.x.x are private.

The setup

For this post, I assume all routers can reach each other as they should. Only the “interesting” commands are shown below.

The GRE tunnel is sourced on the far left by “GreL”:

interface Tunnel0
 tunnel source FastEthernet0/0
 tunnel destination 172.16.2.4
interface FastEthernet0/0
 ip address 172.16.1.1 255.255.255.0

This GRE tunnel is encapsulated in an IPsec tunnel at device “IPsecL”:

crypto isakmp policy 1
 hash md5
 authentication pre-share
 lifetime 3600

crypto isakmp key SHAREDKEY address 172.16.2.4

crypto ipsec transform-set IPSEC_TS_NULL esp-null esp-md5-hmac

crypto map CRYPTOMAP_1 1 ipsec-isakmp
 set peer 172.16.2.4
 set transform-set IPSEC_TS_NULL
 match address ACL_GRE

interface FastEthernet0/0
 ip address 172.16.2.2 255.255.255.0
 crypto map CRYPTOMAP_1

ip access-list extended ACL_GRE
 permit gre host 172.16.1.1 host 172.16.2.4

The “Nat” router is fairly simple:

interface FastEthernet0/0
 ip nat outside

interface FastEthernet0/1
 ip nat inside

ip nat inside source static 10.0.0.4 172.16.2.4

The magic

The magic happens at router “R”. The problem is that the GRE needs to be terminated on the public IP. The left end of the connection is unaware of any NAT, and the NAT can’t change the GRE-IP-header since it’s protected by the IPsec.

There are probably other ways around this, but I solved the issue by adding a loopback interface with 172.16.2.4/32 as IP:

crypto isakmp policy 1
 hash md5
 authentication pre-share
 lifetime 3600

crypto isakmp key SHAREDKEY address 172.16.2.2

crypto ipsec transform-set IPSEC_TS_NULL esp-null esp-md5-hmac 

crypto map CRYPTOMAP_1 1 ipsec-isakmp
 set peer 172.16.2.2
 set transform-set IPSEC_TS_NULL
 match address ACL_GRE

interface Loopback0
 ip address 172.16.2.4 255.255.255.255

interface Tunnel0
 tunnel source Loopback0
 tunnel destination 172.16.1.1

interface FastEthernet0/0
 ip address 10.0.0.4 255.255.255.0
 crypto map CRYPTOMAP_1

ip access-list extended ACL_GRE
 permit gre host 172.16.2.4 host 172.16.1.1

The Results

I verified this setup to work in dynamips. I pinged from 10.0.1.1 to 10.0.4.4. Here are the packet dumps for the ICMP packet on its way from left to right.

The reply on its way back from right to left:

]]> http://blog.dest-unreach.be/2008/07/11/terminating-an-ipsec-gre-tunnel-behind-nat/feed 0