ipsidixit.net » shorewall

Content filtering in a home network

sgroarke — Mon, 07 Feb 2011 11:04:23 +0000

With two young children starting to make increasing use of the Internet, my attention has turned in recent times to the thorny subject of Content Filtering. This posting is actually going to look at a technical approach I settled upon, however one cannot help mentioning, at least in passing, some of the wider issues involved.

As a parent I do not believe in raising children in some sort of bubble, totally devoid of anything that could possibly “harm” them. That applies to the Internet too – my hope is to raise children who are able to understand and deal with things, rather than require protection from them. To that end, Internet access for my children involves their parents first and foremost! They use a laptop, after asking permission, in the kitchen, in view of everyone else. I’m interested in what they are doing on it (genuinely so, not as some excuse to snoop!) and they want me to help and guide them. Email? Sure, make full use of it. But all emails sent to your address also get forwarded to me too guys… Why? So I can see what you’re receiving! Very open. Very honest. Nothing underhand. Those are the rules in this house.

And that approach actually covers probably 90% of what is required. However there’s still a small part that needs attention. As most adults know, there’s some weird stuff in some corners of the Internet. Really weird. Disturbingly weird. Stuff which I do not want my young children to see, even if accidentally. Being a very liberal sort, and totally anti-censorship with regard to what consenting adults view, I do not support any move to remove such stuff from the Internet. Weird, sick, depraved, whatever… Some of it may not be at all nice, but it’s there and it can be found. I just don’t want young children to accidentally find it. So what is a network engineer father to do…?

Content filtering – 4 approaches

Broadly speaking there are four way of approaching content filtering in the home environment:

Workstation filtering
Network filtering
ISP filtering
DNS blocking

The first three are all variations on the same theme. They vary in terms of the “Where do you do it?”

Workstation

There are many software packages out there which will filter content locally on the PC being used to browse the web. In a similar manner to that used by the more familiar virus detection software, one can purchase and run content filtering software which aims to identify and block various categories of content. The difficulty faced with this approach is that it’s not at all easy to identify what to block! Just to take the most obvious candidate category for blocking: pornography. The software can, and will, have lists of the names of the popular, known web-sites with porn. And with some enormous proportion of the Internet being porn, that will already be a long long list! Then we have the challenge of the fact that every day goodness knows how many hundreds of new porn sites will appear, and old ones disappear. The list of sites cannot be fully up to date. So the software will also need to include elements of heuristic detection: identifying porn indirectly and blocking it. So we’re now into looking and scanning all the traffic to and fro for words or patterns which might identify it as porn. And so on. It’s a computationally intensive exercise, and requires frequent updating with new lists of patterns, URLs, IP addresses and so on.

The task is very similar to virus detection, with the frequent updates required, slowing down of communication to an extent, higher CPU usage, and so on.

The software out there is worth consideration for some – I’m not saying it’s a bad approach. But it has unavoidable limitations. Two obvious ones which apply to me are:

Locked to a particular PC – If I install the software on one PC, then I cannot let the kids use another PC as it will be unprotected, unless I pay for and install the software there too.
Linux. A big issue for me is that we only have a single Windows PC in the house (hooray!) All the others (too many… way too many…) including that used by the children, run Linux. And such packages are few and far between for Linux…

Home network

An approach I used for a while, with success, was to filter on the gateway device on my network. A quick summary here: at home my Internet connection terminates on a gateway firewall/router system. This system performs all manner of network-related functions. The key one is to run my Linux-based firewall. A host of other jobs get handled by this box too: VPN termination, media serving, DHCP, IPv6 routing, the list is long. Given that all of our Internet traffic traverses this system it is ideally suited to perform a filtering function.

To that end, for a while I ran Dans Guardian on my firewall. This is a sophisticated bit of software, and not entirely trivial to set up and get working. Apart from quite a lot of configuration itself, it also requires a web-proxy to be running on the firewall. I ran squid to fulfil that requirement. And then there’s the requirement to “hook” users into it. That involves either configuring the workstation to use a designated web proxy (and possible authentication required there – depends upon what exactly you want to achieve) or using IPTables on the firewall to intercept traffic from a given workstation and force it via the proxy. Various approaches, all quite interesting, but only if you find networks interesting… Many would find it simply “complicated”.

Once up and running, however, there are then further challenges to be faced. Firstly there’s the question of overhead. That is, how much load does it place on the gateway device, and hence how much delay or slowness does it introduce to the web browsing. My kids may not need the snappiest, lightening fast response times possible, but nor do they want to wait tens of seconds to see a page, or have some You Tube video constantly stop and start. Let me be clear here (and make sure I’m fair to Dans Guardian): if the device running it is powerful (in terms of CPU, memory, disk and so on) then it’s great. Really good. Trouble is, however, that a lot of boxes used as gateway routers/firewalls are not, by their nature, so highly specified. And that applied to me. My installation was, frankly, not fast enough. Much of the time it would work OK-ish, but often there would be very long delays indeed.

If you have a powerful box you can dedicate to such filtering, then do go ahead and consider it.

On other issue I also had to tackle was that of updates: as described for the Workstation solution, filtering software, wherever it is located, needs to be kept up to date. Dans Guardian does not come with an update mechanism, nor source of updates. There are sources of such updates out there if you search, but again, it’s an extra piece of work to do this and get it all set up correctly, auto updating silently every day. As before, not a criticism of the software that has been made freely available – but something that does need to be taken in to account.

ISP

Many ISPs offer a filtering service to their customers. This is of course attractive, as it entirely removes the need to perform the filtering and blocking locally to the home network. The work is offloaded to the ISP. While there may be a charge associated with this, it may be worth considering. The main, and maybe for many significant, disadvantage to it is the all-or-nothing approach. If you have many PCs (and hence different users) within the home network, you may only want to block certain stuff from certain PCs. I may not want my kids viewing DominatrixFrenchMaids.com, but (purely for research purposes, of course) their father may need to. (God knows, such a site probably exists, but I dare not look…) More realistically, there are other sites which are more genuinely OK for adults, but not for young children. If one has an interest in 20th Century history, a sad reflection on humankind is that there are some horrible things which can be seen… For older children and adults, that’s fine and indeed educational. But not below a certain age. I’d like to maintain the illusion of a nice world for at least a little while longer.

So ISP filtering is attractive in terms of removing the work from the home. But it does come, in general, with a certain amount of inflexibility.

DNS blocking

This last technique is somewhat different from the others. Most people have at least some awareness that the names we use on the Internet (www.ipsidixit.net) actually map on to so-called IP addresses. For example www.ipsidixit.net is mapped via a DNS (Domain Name Service) to the IP address 217.70.191.54 (And to IPv6 2001:4b98:dc0:41:216:3eff:feaa:964a – I’m soooo hip and trendy…)

Yet no one in their right mind (nor even a network engineer) bothers with the numerical version. You just bang in the name and have your computer us DNS to resolve it to an IP address.

Most PCs will use one or more DNS devices specified and operated by their ISP. Used “normally, for example, my ISP (free.fr) provides two DNS systems for workstations to use.

However one does not need to use their suggestions. One can, in general, use other DNSs operated by third-parties.

The point is, then, that if one used a DNS service which had a constantly updated blacklist of sites which are “undesirable”, one could block access to them by simply declining to resolve them to their correct address. This then offers the benefits of ISP Blocking in so far as the load of shifted outside of the home network, but with the added flexibility that only workstations that require protection need use the “filtering” DNS. Other workstations can use the normal DNS.

I found that OpenDNS provide such a service, and have stated to make use of it. It’s free (they have some paid options too – but the free one seems fine for me) I have no association with OpenDNS, and am only “promoting” them as what they offer seems neat and useful. If others have knowledge of other similar services, please do post them in a comment – I’m not trying to make this exclusive to OpenDNS! In fact I’d like to compare OpenDNS to some others.

The service they offer is to provide DNS addresses which can have a selectable level of filtering applied. The spectrum is covered, from porn, violence, drug use, etc. through to shopping sites, social networking sites, etc. You get to choose which categories to block and which to allow.

And it does seem to work really rather well indeed. Below I am going to detail how I set it up within my network, integrating it within the DNS caching system already used.

The main weakness of the system is that with some knowledge and effort it can be circumvented (as, of course, can most systems) One could take the trouble to manually find the Name <–> IP mapping for a domain and enter that directly into a browser, thereby bypassing the DNS. However such a bypass would be very cumbersome to use, since even if you use an IP to land on a page, probably any link off that page will in turn require DNS, and would then need to be manually decoded, etc. Workable, but hard work. By the time my kids are knowledgeable enough to work all that out, they will probably be old enough to look after themselves!

Integrating OpenDNS into a Linux firewall, already running DNSMasq

My home network has DNSMasq running on a central gateway/server/firewall box. DNSMasq is responsible for DHCP (i.e. allocating IP addresses on my home network) and also DNS caching. To that end, it announces, via DHCP, that it is the DHCP server to be used by devices. Then it, in turn, resolves addresses via the ISP-supplied DNSs. It caches then DNS lookups locally.

In the DHCP configuration it has a pool of addresses available for any device to use, but most of the devices on the network have pre-allocated addressees reserved for them within the DNSMasq configuration. These are allocated based upon the Ethernet MAC address of a device. This is a very common technique to use with DHCP.

Given that, where now a device will be handed an IP address and the address of a DNS server to use (where that DNS server will actually be the same as the DNSMasq device itself) we want to change the config so that for certain devices (the childrens’ PC) when an IP address is handed out it will instead be given with the DNS addresses of the OpenDNS filtering systems. Then all DNS requests from that PC will no longer be locally forwarded to the gateway device, but will instead be routed out externally to OpenDNS, where they can be answered or blocked as appropriate.

The DNSMasq config to achieve this is slightly fiddly, so I am providing it here more or less in its entirety (a few names omitted and some light obfuscation of MACs etc.), but only highlighting the parts that particularly pertain to the OpenDNS filtering setup.

# Configuration file for dnsmasq.
domain-needed
resolv-file=/etc/resolv.conf
no-resolv
no-poll

# Add other name servers here, with domain specs if they are for
# non-public domains.
server=/localnet/192.168.0.22

This part is not related to OpenDNS in any way: I don't use my ISP's DNS for normal use - I instead use Google's Public DNS.
# Google Public DNS servers
server=8.8.8.8
server=8.8.4.4

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only.
local=/localnet/

interface=eth1
expand-hosts
domain=localnet

# For general purpose use, use this range.
dhcp-range=192.168.0.128,192.168.0.160,12h

This is for OpenDNS. We use the dhcp-mac config to tag these special devices for filtering:
# MAC list for openDNS filtering
dhcp-mac=opendns,00:c0:9f:12:34:56	# Laptop on-board
dhcp-mac=opendns,00:90:4b:12:34:56	# Laptop wifi

Here we're back for normal dhcp-host preallocation for known unfiltered devices:
# Most ip addresses are pre-allocated here
dhcp-host=00:50:ba:12:34:56,aname,192.168.0.2,720m
dhcp-host=00:18:8B:12:34:56,anothername,192.168.0.3,5m
dhcp-host=00:90:4b:12:34:56,laptop_wifi,192.168.0.4,720m
dhcp-host=00:26:37:12:34:56,galaxy,192.168.0.5,60m
dhcp-host=00:18:41:12:34:56,magic,192.168.0.6,60m
dhcp-host=00:26:82:12:34:56,eva9150,192.168.0.7,720m
dhcp-host=00:c0:9f:12:34:56,laptop_eth,192.168.0.8,720m
dhcp-host=00:14:29:12:34:56,camera,192.168.0.10,120m
dhcp-host=00:21:5A:12:34:56,printer,192.168.0.11,720m
dhcp-host=00:40:63:12:34:56,aservername,192.168.0.22,infinitem

The devices tagged "opendns" above here get special DHCP options pointing them to the OpenDNS filtering-servers.
# OpenDNS content filtering servers
# Specify the two OpenDNS first, then ourselves third for local stuff
dhcp-option=opendns,6,208.67.222.222,208.67.220.220,192.168.0.22

Note also the "192.169.0.22" on the end - this is optional, if you still want the filtered devices to be able to resolve local names.

dhcp-authoritative
cache-size=150
clear-on-reload

Anyone who has an existing DNSMasq configuration should find the above more than enough to change it to point arbitrary devices at the OpenDNS systems.

Summary

Nothing, but nothing, replaces a conscientious adult supervising, guiding and helping get to grips with the Internet. However even with that it’s still all too easy for some stuff to pop up which is better left hidden! This article highlight some of the general technical approaches one can take, and in particular that of DNS filtering with a service such as OpenDNS, optionally using a Linux device to semi-automatically allocate filtering to some device but not others.

IPv6 – Proxy the neighbors (or come back ARP – we loved you really)

sgroarke — Wed, 24 Mar 2010 09:11:32 +0000

After three articles, where am I with my venture in to IPv6? What have we really achieved so far? Well, in functional terms, not so very much yet!!

To recap:

Here I covered a lot of ground, getting basic IPv6 running on a Linux gateway box connected to an ISP providing native IPv6, while remembering stuff like the need to set up a firewall.
Here I looked at the issue of IPv6 firewall logging
And here I looked at the need to set up a default route out of the gateway device pointing back towards the internet.

And what can I now actually do? Well……. from the gateway box I can ping out successfully to any IPv6 device on the Internet. In other words, logged in to the device in green on this diagram, I can ping out of eth0 over the Internet. And from an IPv6 device on the Internet I can successfully ping towards my green box, using the address of eth0. So I can ping from the Internet to (these are of course made-up addresses!) 123::456.

However if from my remote Internet location I ping instead the IPv6 address of eth1 (here 123::789) does it work? I might expect it to: after all, eth1 has a global IPv6 address on it, not a private address. So surely I can ping it?

Needless to say, as it stands I cannot. Here we look at why not – in the process covering an important element of turning our gateway device in to an IPv6 router (which, grand though it sounds, is exactly what we are doing here!) which receives very little coverage elsewhere on the Internet. In fact when researching this I came to a conclusion that the vast majority of folks who have dabbled with IPv6 in the domestic environment have terminated their ISP IPv6 connection on their workstation, and very few have gone the step further and used a device as a gateway to a home network!!

How to get through the gateway – or Come back ARP, all is forgiven

So when I ping 123::789 what stops it working? The first thought is: firewall. We’re blocking it, right? A quick trip to the shorewall6 log (glad we set that up, eh?) shows us: nothing. Nowt. Zilch. Nada. Surprisingly, we’re not dropping the ping. (In fact the firewall config we set up in the first of these articles contains enough already to allow, from a firewall perspective, for this ping to succeed.)

So we now run tcpdump on eth0 to see just what is going on. Here’s an example:

From the remote host

From my remote IPv6 host I do and see:

ping6 2a01:XXX:8b25:7ea0::22

PING 2a01:XXX:8b25:7ea0::22(2a01:XXX:8b25:7ea0::22) 56 data bytes

From 2a01:XXX:8b25:7ea0::1 icmp_seq=1 Destination unreachable: Address unreachable

From 2a01:XXX:8b25:7ea0::1 icmp_seq=2 Destination unreachable: Address unreachable

From 2a01:XXX:8b25:7ea0::1 icmp_seq=3 Destination unreachable: Address unreachable

.

.

.

Which doesn’t tell me a lot.

On the gateway

On my gateway, from tcpdump, I see:

tcpdump -i eth0 -v ip6

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

08:51:35.315038 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:XXX > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:XXX:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

08:51:36.315002 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:XXX > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:XXX:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

08:51:37.315001 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:XXX > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:XXX:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

What does this tell me?

So the ping is reaching the gateway device alright. Sort of. Well, not really. But there’s something going on there! What we see in that tcpdump trace is the ISP’s router to which I’m connected is sending me a Neighbor Solicitation for the ::22 address (i.e. the global IPv6 address of my eth1 interface on the “far side” of my gateway which I’m trying to ping) While I’m not keen to draw too many parallels and comparisons with IPv4, it is useful to do so here: A Neighbor Solicitation is, at least as we see it here, pretty much analogous to a good ol’ ARP Request. The ISP is saying to us “I think this address is somewhere over with you – Please confirm and let me know how to reach it”. Which is great, except for the glaring fact that we appear to ignore this NS (Neighbor Solicitation) and hence the ping fails.

So you can guess we need to set something up on the gateway that tells it to reply to such a NS. (Kinda vaguely analogous to a Proxy ARP, if you’re familiar with that)

IPv6 Proxy

A couple of steps here. Firstly the system needs to be told globally to perform the required IPv6 proxying, and we then need to enable it for specific addresses.

proxy_ndp

In the /etc/sysctl.conf file add a line:

net.ipv6.conf.all.proxy_ndp = 1

To set this dynamically (without a reboot) you can also do:

sysctl -w net.ipv6.conf.all.proxy_ndp=1

Neighbor proxy

Then perform:

ip -6 neigh add proxy 2a01:XXX:8b25:7ea0::22 dev eth0

Note that here the IPv6 address is the address of the interface on the private side of the gateway (eth1 for me). The end part “…dev eth0″ is to say “Proxy that address from this interface”.

You also, of course, will need to make such configuration permanent. Numerous approaches to that: I settled upon adding this from the interface-up scripts in /etc/network/if-up.d/ but there are so many other methods too. Pick yours.

(Interestingly, I have yet to discover any way at all to display the list of proxied neighbors added in this manner! I’ve looked pretty hard, but there appears to be no way I can find to have them listed. There must be a way, but I can’t find it.)

Success!

And the ping now works, with a tcpdump like this now showing to us:

09:18:18.644817 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::207:cbff:fea5:XXX > ff02::1:ff00:22: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a01:XXX:8b25:7ea0::22

source link-address option (1), length 8 (1): 00:07:cb:a5:1a:68

09:18:18.868550 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::240:63ff:fef5:XXX > fe80::207:cbff:fea5:XXX: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a01:XXX:8b25:7ea0::22, Flags [solicited]

destination link-address option (2), length 8 (1): 00:40:63:f5:f9:3c

09:18:18.868958 IP6 (hlim 56, next-header ICMPv6 (58) payload length: 64) ipsi6 > 2a01:XXX:8b25:7ea0::22: ICMP6, echo request, length 64, seq 5

09:18:18.869107 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2a01:XXX:8b25:7ea0::22 > ipsi6: ICMP6, echo reply, length 64, seq 5

Which has 4 elements:

The same sort of Neighbor Solicitation we had previously.
This time we send back a Neighbor Advertisement for the ::22 address
With that done, the ping itself can come to us (the ICMP6 echo request)
And we of course respond to the ping with ICMP6 echo reply.

Conclusions and summary

In the world of IPv6, with no ARP or NAT, life is different. Devices which in IPv4 are thought of as private (both in terms of addressing and functionality) are now, at least from the perspective of addressing, public. We need to make sure that if we want “The World” to be able to reach them, we must in turn tell the world about them. Hence the need for IPv6 neighbor proxying. And, thinking ahead a little, the need to take our firewalling ever more seriously. If I make the addresses of a “private” workstation globally reachable I’d better make sure that it’s protected…

The last point to make is about scalability: do we really need to add an “ip -6 neigh add proxy” for each private device we wish to be able to reach from the Internet? If there are only a few devices (as in the typical home network) then it may well be easiest to do this. However in situations where the private side of the network has many IPv6 addresses which need to be globally reachable, other solutions may be more appropriate and manageable, but will not be covered here. Here we’re trying to get a small home network IPv6 enabled, not migrate a corporation to IPv6. If you really want to get in to the area of automating these functions you need to read up on implementations of Neighbor Discovery Protocol, look at “zeroconfig” networking, Apple’s Bonjour service, and so on..

There will come a time when such automation will be required at the domestic level, with the eventual proliferation of networked devices. But for now we keep it simple and statically configure the required addresses.

EDIT 5 Aug 2011: npd6 – See project here http://www.ipsidixit.net/2011/08/04/npd6/

IPv6 – logging and shorewall6

sgroarke — Thu, 25 Feb 2010 11:42:32 +0000

Following on from my early success at get IPv6 running, I soon hit a significant issue: firewall logging.

Now this need not be a “blocker” for everyone, but I take my firewall logging duties quite seriously…!

shorewall IPv4 logging

Currently I have IPv4 shorewall configured to log not using the standard syslog mechanism, but instead to use ulogd. This allows me to easily log firewall activity to an entirely separate set of log files very easily. It is absolutely not mandatory, but it’s neat and tidy. I then have fwlogwatch to nightly analyse the logs and automatically email the interesting bits to me for occasional checking.

To enable this I have appropriate pointers to use of ULOG in shorewall’s policy and rules files as follows:

policy

.

.

.

ext all DROP ULOG

.

.

.

and, for example:

rules

.

.

.

ACCEPT:ULOG all fwall 47
.
.
.

One then has an appropriate config in /etc/ulogd.conf to file things where you want them.

shorewall6 IPv6 logging

Having installed shorewall6 in a simple form and got it working, I naively assumed I could log in a similar manner as with the IPv4 version of shorewall. Oh no – I find ulogd is no longer supported in shorewall6 and the choices are:

syslog
nflog

The syslog option I specifically did not want, so I decided I’d better find out about nflog (Net Filter Log). It turns out that nflog is actually more commonly referred to as ulogd2, and is a dramatically enhanced version of the original ulog. In fact it’s so different that it is, for all practical purposes, an entirely different thing. Trying to relate ulog to ulog2 is a pretty futile exercise. Work on the basis that they are unrelated and it’ll prove less frustrating.

Anyway, the learning curve with ulogd2 was a bit steep, but it turns out to be a very neat product. Here I will present some key points that should help you to get it up, running and integrated on a Ubuntu system. Oh, and it’s not available as a pre-built package… Sorry – didn’t I mention that?

Implementing NFLOG (aka ulogd2) on a Ubuntu firewall

The first step to follow is to get hold of the ulogd2 source tree and build it. I worried that this would take me some time, but found a tremendously helpful article someone had already written which aided me a lot. (Thank you Pollux!)

If you’re familiar with building from source, that page will give you most of what you need. Here are a few points to add:

I’d suggest leaving the build PREFIX unspecified (i.e. default) so it will ultimately install in the /usr/local/ hierarchy. This means you can get it all working in parallel with an existing ulogd installation – much cleaner and safer!
Since we want to emulate ulogd just in so far as we are able to log to a disk file, disable any of the Postgres or MySQL build options to make things more compact and simple (unless of course you want to make use of these neat new features within ulogd2!)
Much of the article referenced assume that you will be logging to a database – keep it simple for now and ignore that.

ulogd2 config highlights

Once ulogd2 is installed, you need to copy the supplied ulogd.conf from the source tree you used to build into /usr/local/etc.

The contents of this file took a little working out, but here I present the key elements required in order to have ulogd2 set up to allow:

IPv6 to be logged to one file
IPv4 to be logged to another file (this used to be done using the original ulogd)

Once completed and the two shorewall configs tweaked to make use of it, this new ulogd2 replaces the previously used ulogd. Note that this is optional: you can have both versions of ulogd coexist. However it’s a lot cleaner and easier to maintain if just one subsystem is used. But that’s entirely a personal choice.

plugins section

plugin="/usr/local/lib/ulogd/ulogd_inppkt_NFLOG.so"
plugin="/usr/local/lib/ulogd/ulogd_inppkt_ULOG.so"
plugin="/usr/local/lib/ulogd/ulogd_inpflow_NFCT.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_IFINDEX.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_IP2STR.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_IP2BIN.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_PRINTPKT.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_HWHDR.so"
plugin="/usr/local/lib/ulogd/ulogd_filter_PRINTFLOW.so"
#plugin="/usr/local/lib/ulogd/ulogd_filter_MARK.so"
plugin="/usr/local/lib/ulogd/ulogd_output_LOGEMU.so"
plugin="/usr/local/lib/ulogd/ulogd_output_SYSLOG.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_OPRINT.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_NACCT.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_PCAP.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_PGSQL.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_MYSQL.so"
#plugin="/usr/local/lib/ulogd/ulogd_output_DBI.so"
plugin="/usr/local/lib/ulogd/ulogd_raw2packet_BASE.so"

stacks section

# this is a stack for logging packets to syslog after a collect via NFLOG
stack=log4:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu4:LOGEMU
stack=log6:NFLOG,base1:BASE,ifi1:IFINDEX,ip2str1:IP2STR,print1:PRINTPKT,emu6:LOGEMU

log section

# Using log4 for IPv4
[log4]
group=4
numeric_lable=4
# Using log6 for IPv6
[log6]
group=6
numeric_label=6

log-specific sections

# IPv4
[emu4]
file="/var/log/firewall/nflog4.log"
sync=1
# IPv6
[emu6]
file="/var/log/firewall/nflog6.log"
sync=1

Changes to shorewall configs

And finally we need to tweak shorewall and shorewallt6 to use the new log facility. For shorewall6 that means simply adding the appropriate NFLOG references within the policies and/or rules. For shorewall IPv4 one simply has to replace existing ULOG references with an appropriate NFLOG reference.

shorewall6 additions

So my (very very over-logged – but then my IPv6 is still at the experimental stage…!) policy file is now:

#Source Dest Policy Log Burst/Limit

fwall all DROP NFLOG(6)

int all DROP NFLOG(6)

ext all DROP NFLOG(6)

all all DROP NFLOG(6)

And to test logging from individual rules I’ve specified rules as:

ACCEPT:NFLOG(6) ext fwall ipv6-icmp

ACCEPT:NFLOG(6) fwall ext ipv6-icmp

shorewall (IPv4) changes

And over in my IPv4 shorewall I just changed any reference to ULOG to read NFLOG(4), for example, where policy previously read:

office all DROP ULOG

it now reads

office all DROP NFLOG(4)

In Summary

If you are implementing IPv6 with shorewall6, ulog cannot be used for logging. You must either go back to the crude-but-efective use of syslog or go forward to NFLOG / ulogd2. Implementing ulogd2 is not entirely trivial, since it is not yet a pre-built package for Ubuntu. However building and implementing it is far from impossible if you’ve a little experience in such matters. And as a bonus, once implemented you can drop the original ulog and integrate both IPv4 and IPv6 logging within NFLOG.

Worth noting is that while we’ve achieved an elegant split between IPv4 and IPv6 firewall logs using ulog2d, while I can continue to process my IPv4 logs every night using fwlogwatch, as before, the processing and analysis of the IPv6 logs is another issue altogether! fwlogwatch is an old tool and does not process IPv6 log files. I’ll sort that out in a later article.

IPv6 at home – a guide to getting started

sgroarke — Wed, 24 Feb 2010 08:36:50 +0000

With IPv6 slowly becoming more visible, it was time to get to grips with it. While absolutely not essential (yet!) it seemed like a fun idea: my ADSL provider offers native IPv6 in parallel with IPv4, and my hosting provider is running an IPv6 beta. So I can do native IPv6 end to end between my home and a remote host. “Home” in this case consists of a Linux firewall running iptables, fronted by shorewall. Two ethernet ports: one to the ADSL modem (my “external” interface) and one to the house infrastructure (“internal”)

The Ubuntu server distribution in use is, like most Linux distros, fully IPv6 ready. For example, do an ifconfig and we see

Link encap:Ethernet HWaddr 00:40:63:f5:f9:3c

inet addr:88.XXX.XX.XXX Bcast:88.XXX.XXX.255 Mask:255.255.255.0

inet6 addr: fe80::240:63ff:fef5:XXX/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:14086899 errors:0 dropped:0 overruns:0 frame:0

TX packets:15607323 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:1837525573 (1.8 GB) TX bytes:666354591 (666.3 MB)

Interrupt:16 Base address:0×8000

Now I may not know much about IPv6 on Linux yet, but I can see that I’ve got a line beginning “inet addr” which looks kinda IPv6-ish. Good start. Let’s go…

[EDIT: Had to obfuscate parts of addresses below... Sorry, makes reading a tad harder in places...]

IPv4 – today

As it stands, my home firewall performs the following functions:

It acts as a DHCP client on its external interface, in order to pick up from the ISP the IPv4 address, plus the DNS server(s) being offered. In fact my IPv4 address is fixed, so strictly speaking I don’t need to act as a DHCP client on this interface, but it’s no real effort to do so and it means I get the DNS servers automatically.
It acts as a DHCP server on its internal interface, in order to supply IP addresses to the many and various client devices within the house, along with DNS information. (I actually use dnsmasq for this purpose – tremendous piece of software)
It performs NAT between the internal devices and the Internet, courtesy of iptables.
It acts as a firewall between the internal devices and the Internet, again courtesy of iptables.

Since no one in their right mind writes “raw” iptables configs of any complexity, I use shorewall to administer the NAT and firewall functions – mostly using the shorewall cli, sometimes using the shorewall GUI within Webmin.

To top things off, I also have a VPN tunnel running between the firewall and a host machine, using OpenVPN.

So what do I need to know even before I think of starting with IPv6?

So as far as I know all the raw elements are available to me: ISP support, host support and all the bit ‘n bobs that Linux offers. So how do I string them together? In fact, hang on a sec before that: Just what is my goal?? The engineer in me frankly just wants to have a damn good play with IPv6, but it’s still good to have an initial goal to provide some sort of framework and direction.

Hence I set myself the somewhat arbitrary goals as follows:

Between my firewall and my remote host enable simple IPv6 connectivity. ping, ssh, etc.
Between my firewall and my remote host enable VPN connectivity (i.e. shift the existing IPv4 tunnel to IPv6)
While leaving the rest of the household blissfully ignorant (and hence unaffected) by IPv6, enable two specific workstations (one Windows, one Linux) to have dual IPv4/IPv6 stacks such that they default to using IPv4 except for traffic destined to the remote host or some other IPv6 end-point, which will go IPv6 end-to-end (i.e. workstation <–> firewall <–> host)

Note that there are a lot of things that I am not yet trying to do. Specifically I am not setting up any gateways to allow IPv4 <–> IPv6 inter-working. For now I will have all my existing IPv4 functionality, with an entirely optional layer of IPv6 for those clients who (a) can talk native IPv6 and (b) have an IPv6 end-point to which they wish to connect. The inter-working side of things is a level of complication that in the first instance I want to avoid. Start simple and build up.

IPv6 Basics

Before anything else there are some IPv6 “basics” that need a little explanation and clarification. As with any technology, the problem is not with finding information. The problem is with finding out which information is useful and which is entirely irrelevant.

IPv6 Addresses

The one thing everyone knows about IPv6 is that it’s got funny looking, and rather large, addresses. Where once we had stuff like good old 192.168.0.1, now I might have fe80::240:63ff:fef5:f93c/64. And that’s one of the shorter ones…!

So what do I really need to know about IPv6 addresses, leaving aside the stuff that’s not required? Here goes.

IPv6 addresses consist of 128 bits. Why? Simple: to provide enough addresses that we’re not likely to run out, as we are perilously close to doing with IPv4. Just how big is “128 bits”? In decimal terms, such numbers have up to 39 digits. Here’s one:

340282366920938463463374607431768211455

In order to make things more manageable, IPv6 addresses are not written as long, decimal numbers. Instead they are written in hexadecimal, broken up in to 16-bit fields by colons. Here’s an IPv6 address lifted from the official IPv6 HowTo:

2001:0db8:0100:f101:0210:a4ff:fee3:9566

To further simplify things, leading zeros can be omitted. Also, contiguous blocks of zeros can also be omitted. For example:

2001:0db8:0100:f101:0000:0000:0000:0001

can be reduced down to

2001:db8:100:f101::1

The most extreme example of this is when the localhost address is considered (analogous to IPv4′s 127.0.0.1) and can be condensed down from

0000:0000:0000:0000:0000:0000:0000:0001

::1

Note, however, that the use of ‘::’ and leading-zero suppression is purely a shorthand. All IPv6 addresses are 128-bits in length – these are just cosmetic tricks to make the writing and typing of them a little more friendly.

Just as IPv4 addresses have netmasks, so with IPv6 addresses. More of that when we look specifically at routing later on.

Also, normally we find that the upper 64 bits are considered to be “network” bits and the lower 64 bits are “host” bits.

Network bits

The leading 16 bits of the network portion of an IPv6 address are “special” in so far as some values are reserved as having special meaning. I am not here going to define all the possible values in use. I am confining myself to what matters within the context of the exercise at hand. And for those purposes the two values might be seen.

Local link addresses prefix

fecx (where x is any hex digit, but is normally 0) – Such addresses are local link addresses. Under Linux, when an IPv6-capable interface is enabled, such an address “automatically” appears. It is used solely to talk with other devices on the same link: hi, anything there? anyone looking for a router? Note that such addresses are not used for “normal” data – they are purely for local link management. And now we know where that IPv6-looking address came from in my original ifconfig command:

inet6 addr: fe80::240:63ff:fef5:XXX/64 Scope:Link

(and notice that friendly Linux even puts the “Link” there to remind you that it’s a link address)

Global unicast address prefix

2xxx and 3xxx – These are so-called “global unicast” addresses, analogous to IPv4 “normal” addresses (i.e. not private, not multicast, etc.)

Host bits

The bottom 64 bits of an IPv6 address are, essentially, whatever you want them to be. They can be manually defined or, more often, are computed by using the interfaces MAC address (if it has one).

So here’s a simple enough address:

2001:0db8:100:f101::1

Given the 2001:prefix, so we know it’s a global unicast address from an ISP. And the bottom 64 bits consists of just ’1′ (all the zeros are magic’ed away by the ‘::’)

But what of this “computed from the MAC address”? Recalling the ifconfig I showed back at the start:

Link encap:Ethernet HWaddr 00:40:63:f5:f9:3c

inet addr:88.XXX.XX.XXX Bcast:88.XXX.XXX.255 Mask:255.255.255.0

inet6 addr: fe80::240:63ff:fef5:XXX/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:14086899 errors:0 dropped:0 overruns:0 frame:0

TX packets:15607323 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:1837525573 (1.8 GB) TX bytes:666354591 (666.3 MB)

Interrupt:16 Base address:0×8000

Note the hardware MAC address: 00:40:63:f5:f9:3c (and remember that those digits and colons are nothing at all to do with IPv6 notation – they are bog-standard, traditional L2 MAC address format)

Now look at the last part of the IPv6 link address: you will see that there is more than a passing resemblance between them – although also note that they are not identical either. The details of how one is morphed in to the other is not of direct concern to us – all we need to know here is that one follows from the other.

A complete example

Here’s one I prepared earlier….. This is the output from ifconfig on my host system, after the main interface has been fully configured and all addresses allocated:

Link encap:Ethernet HWaddr 00:16:3e:2e:50:36

inet addr:217.XXX.XXX.XXX Bcast:217.XXX.XXX.255 Mask:255.255.252.0

inet6 addr: fe80::216:3eff:fe2e:XXX/64 Scope:Link

inet6 addr: 2001:XXX:41::d946:bf36:54/128 Scope:Global

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:122352 errors:0 dropped:0 overruns:0 frame:0

TX packets:68714 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:34644771 (34.6 MB) TX bytes:62489400 (62.4 MB)

What have we got? The interesting parts break down as follows:

The interface has a L2 MAC address of 00:16:3e:2e:50:36
The IPv4 addressing is as it always has been – No change there.
We have a Link address of fe80::216:3eff:fe2e:XXX which should now look familiar: the fe80: prefix and the appearance of the L2 MAC address.
And we now have a Global address of 2001:XXX:41::d946:bf36:54 which is familiar at least in so much as it has a prefix of 2001: The rest of the address’s derivation is not of direct concern here. (In fact, after the ISP-specific part, other elements of it are derived from VLAN addresses and other such stuff. No matter.)

Goodbye ifconfig, hello ip

Since time immemorial Linux users have been familiar with the command ifconfig. Thus far in this document I’ve used it too, for the sake of familiarity. But dear ifconfig has actually been deprecated now for many years. It lives on, and we all still use it, but with the advent of IPv6 it does now seem an appropriate moment to bid it goodbye. It’s time to use the ip command, in its many forms. While it’s true that ifconfig can still achieve most of what is required, it sometimes falls short. Also, using ip let’s us more clearly and easily distinguish between IPv4 and IPv6, which is maybe not a bad thing!

Compare the ifconfig output from above with a couple of examples of the ip command:

ip addr show dev eth0

2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 00:16:3e:2e:50:36 brd ff:ff:ff:ff:ff:ff

inet 217.XXX.XXX.XXX/22 brd 217.XXX.XXX.255 scope global eth0

inet6 2001:XXX:41::d946:bf36:54/128 scope global

valid_lft forever preferred_lft forever

inet6 fe80::216:3eff:fe2e:XXX/64 scope link

valid_lft forever preferred_lft forever

This is analogous to the simple ifconfig: we’ve got L2 MAC, IPv4, and a couple of IPv6 addresses showing.

ip -4 addr show dev eth0

2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

inet 217.XXX.XXX.XXX/22 brd 217.XXX.XXX.255 scope global eth0

Look how much neater that is, even just for IPv4: no L2 MAC, no IPv6, just the IPv4-related information.

ip -6 addr show

1: lo: mtu 16436

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: mtu 1500 qlen 1000

inet6 2001:XXX:41::d946:bf36:54/128 scope global

valid_lft forever preferred_lft forever

inet6 fe80::216:3eff:fe2e:XXX/64 scope link

valid_lft forever preferred_lft forever

And similarly here: we just get IPv6-related information, and nothing else.

It may take a little effort to get used to it, but it’s worth the effort. And feel free to make use of alias to make life even easier. If you tire of typing -6 after each invocation of IP, then do something like:

alias ip6=’ip -6′

and then you can just enter:

ip6 addr show

which is quite neat.

Key subsystems

The last part of this IPv6 Basics section is to introduce the functional building blocks within Linux which seem to get mentioned in connection with IPv6.

We now know about IPv6 addresses types that matter to us, we have met the command(s) we will use to inspect and manipulate things such as interfaces, routes and so on. We have also assumed that there is something similar to IPv4 iptables (and we’ll come back to that in some detail later as to how we actually use iptables under IPv6). However what subsystems such as DHCP exist and are of interest to us? When reading up on IPv6 Linux implementation one comes across the following mentioned frequently, and you may quickly form the impression that they are three important elements in an IPv6 firewall/router. They are:

dhcp6c
dhcp6s
radvd

dhcp6c

dhcp6c is a Linux DHCP IPv6 client. It is directly comparable to the IPv4 dhclient or dhclient3. It will, for a nominated interface, call out and ask for an IPv6 address which it can allocate to that interface. It may also, optionally, pick up other information, typically DNS-related.

dhcp6s

dhcp6s is a Linux DHCP IPv6 server. It is comparable to the IPv4 dhcpd or, in my network, dnsmasq. Just as in the IPv4 environment, it hands out addresses to other devices and, optionally, other information such as DNS data.

radvd

radvd is a Router Advertisement Daemon. This is less easy to directly compare to the IPv4 environment. It can hand out, to requesting devices, an IPv6 prefix (not a full address…) and a default route to be used. From this the receiving device can then automatically decide upon a host portion to add to the prefix to give it a full IPv6 address. So at first sight, it seems to be a rather inadequate imitation of a DHCP server!

One might very easily conclude that all three are required. After all, we may well use a DHCP client on the Internet side, and a DHCP server for the private network sounds pretty much essential. And a router advertisement daemon? Not entirely sure what it is, but gets a lot of mentions so I probably need that too! In actual fact the only one of these you are likely to need is readvd. You might need any combination of them, depending upon your precise circumstances. But probably not.

DHCP client I get, but what’s with DHCP server versus radvd?

This is an area of considerable confusion! When bouncing around Google trying to find information on setting up IPv6 one minute we appear to be required to use DHCP server, the next minute we appear to need radvd. Which is which and when do I use them? Do I need both?

Well, the answer to the last question, “Do I need both of them?”, it “Probably not, but you might…”

Coming from familiarity with the world of IPv4 one instinctively tends to feel comfortable with the concept of dhcp6s – and while it can be used, radvd may well be simpler and easier in practice. Or, maybe, both… The attraction of rad is that the server does not need to concern itself with any state: no records of addresses allocated – since it does not allocate any. It just says “Hey, this is the prefix, work the rest out for yourelf.” which is attractively simple! The DHCP server alternative has to remember which address is where and when. The case where you might want both would be where you want to have rad handle the job of initiating address allocation, and then have DHCP pick up to add some icing on the cake: DNS information being the common case.

And us here? We’re going to go with the simpler case, and have radvd handle the job of responding to IPv6-capable devices within our internal network and tell them just enough to allocate addresses themselves and use a default route.

So it actually seems to come down to a pair of subsystems being required:

dhcp6c talks out to the ISP to handle “outside” IPv6 addressing.
radvd talks internally to all devices to handle “inside” IPv6 addressing.

Well, maybe… But in these early days of IPv6 there is far from a standard view of how these things are to work. And, as I discovered, your ISP may not actually themselves offer an IPv6 DHCP server at all! In my case that was the situation, although I have little doubt that as time progresses and IPv6 implementations mature such services will become more standard.

But for now, my implementation will be reduced down to simply running radvd on the firewall, with the IPv6 configuration on Internet side being handled semi-statically.

Just one subsystem to be used: radvd. No DHCP client. No DHCP server. Who said IPv6 was complicated?!?

Setting up the firewall box

So at last we get to the actual practicalities of getting IPv6 up and running on the home firewall. The system in question is a Ubuntu-based device. The differences for another Linux system should be fairly negligible (package names maybe, some config file locations, etc.)

Packages to install

All we need to install is radvd if its not already present. Under Ubuntu something like:

sudo apt-get install radvd

should do the job.

Careful now….

And already we come to potentially our first issue!!! Once radvd is up and running on the firewall it will, potentially, start chatting to devices on the home network which are, by default, on the look out for IPv6 routers. Whether it does this by default depends upon the installed configuration file used, and which interface points where, but it’s a real possibility. And that may not be entirely a good thing. Be on the look out for workstations suddenly getting really really slow when, for example, browsing the web. I would suggest disabling IPv6 on any devices which may be susceptible to it. There are numerous ways to do that. On Windows in all its flavours? I have not the faintest idea. Under Linux? Here are some suggestions. Depending upon what is on your home network this may not be required, but if you do run in to the “slow web” issue, be alert to it.

Technical note: for the curious, if you do hit the IPv6 crawl of death issue, it’s actually due to certain services on clients stations being IPv6 aware and thus trying to resolve DNS requests via IPv6. They try, take an age to fail, and eventually fall back to IPv4. But it’s ugly. I wish I could say that I foresaw the issue and planned accordingly. More truthful would be to say that during my diddling around with radvd I got loud complaints from another user on the home network…

Setting up the connection towards the Internet… no hang on, actually not yet…

The first task is to get the public (in my case eth0) interface up and running IPv6. Before actually doing that we need to pause for a moment and consider the implications of what might happen if we indeed succeed in bringing up the IPv6 ISP-connected interface! We are then wide-open to the world, and just asking to be attacked. The only sensible thing to do is to first set up an IPv6 firewall to provide some level of protection before we throw ourselves open.

Sorry. But that’s life. Of course if your public-side connection is already protected via some firewall, then you can skip this. But it probably isn’t, so pay attention. With IPv4 most home networks make use of, by necessity, NAT. While not done for reasons of security it does nonetheless provide as a side-effect a modest level of security in so far as it tends to block unsolicited incoming connections. So even with a poorly configured firewall under IPv4, the use of NAT hides a multitude of nasties from us. But in the brave new world of IPv6 one hugely important difference from IPv4, but one that everyone seems to gloss over, is that NAT is not required. And indeed since not required, it does not exist. All IPv6 devices on the “inside” network will have, in effect, public addresses. No port-forwarding, no NAT, none of that. And while that’s actually a very refreshing thing in general (NAT and large firewalls are a real pain) it does means we can no longer rely on the default level of safety that NAT provides. A tightly configured firewall is absolutely essential.

To drive IPv6 iptables I use shorewall6. I highly recommend it. Here I am going to run through, without too much explanation, the steps to set up a very basic “block almost everything except a bit of stuff for testing” IPv6 firewall on the system. Here goes.

Install the package:

apt-get install shorewall6

The basic level of configuration then has to take place. Navigate to the configuration files:

cd /etc/shorewall6/

Set up the following files in a similar manner as shown here:

interfaces

ext eth0 -

int eth1 -

zones

int ipv6

ext ipv6

fwall firewall

policy

#Source Dest Policy Log Burst/Limit

fwall all DROP

int all DROP

ext all DROP

all all DROP

rules
# Allow only ping – for testing

ACCEPT ext fwall ipv6-icmp

ACCEPT fwall ext ipv6-icmp

Within shorewall6.conf ensure these lines as as follows:
.
.
.
STARTUP_ENABLED=Yes
.
.
.
IP_FORWARDING=Keep

What we have there is a minimal firewall configuration, which blocks absolutely everything except pings to and from the firewall box itself.

Start up the firewall with e.g.:

/etc/init.d/shorewall6 start

And then

shorewall6 show config

should give you a pretty lengthy IPv6 iptables config.

So, with precautions now in place, we may proceed.

[EDIT: shorewall6 and logging may or may not be an issue... See my article here: http://www.ipsidixit.net/2010/02/25/231/]

OK, finally setting up the connection towards the Internet…

Here is the starting point, with an automatically assigned, MAC-derived, link address:

ip6 add show dev eth0

2: eth0: mtu 1500 qlen 1000

inet6 fe80::240:63ff:fef5:XXX/64 scope link

valid_lft forever preferred_lft forever

Configuring the addressing

My ISP is free.fr (a French ISP) From them I have a fixed IPv4 address and a fixed IPv6 address. My IPv6 address prefix is 2a01:XXX:8b25:7ea0::/64 which looks pretty random but of course is not.

The part 2a01:xx is, from previous knowledge, a global unicast prefix (the 2xxx: indicates that) and the full form 2a01:xx is the RIPE-allocated prefix used by Free. The next part, 58 b2 57 ea? Well, I write is deliberately in that format to show that it breaks down to (decimal): 88 XXX XXX XXX. This, by no coincidence at all, is my current IPv4 address! Of course Free mapping subscribers’ IPv4 addresses into their IPv6 prefix is entirely arbitrary on their part. It indeed seems like a good idea, but is absolutely not required. In the future, for example, IPv4 addresses will not be used in the first place, so no such mapping would be possible.

Of course their network prefix is, as per standard IPv6, 64 bits in length. So the second 64 bits (the host portion) is entirely mine to use as I see fit. That is a seriously large amount of address space, all globally routable, and all entirely mine to use as I wish.

Since my ISP themselves run radvd (or some equivalent) on their routers, when everything is IPv6 enabled on my firewall system, the Internet-facing interface, eth0, should automatically pick up the required prefix and use it. However in addition to the ISP-prefix + MAC-derived host portion I also want a simplified address on the interface. It’s absolutely not required, but I want it to make my life slightly easier.

So prior to the reboot I edit

/etc/network/interfaces

and add a section as follows:

iface eth0 inet6 static

address 2a01:XXX:8b25:7ea0::1

netmask 128

[EDIT 2 Aug 2011: A booboo... the "netmask 64" previously on my eth0 config (and resulting displays) is unlikely to be what you want! If this was a single interface machine, that'd be fine (although pedantically incorrect). But given that eth0 here is the WAN port, and there's "the rest" of that IPv6 network behind eth1, the eth0 interface static address should be defined as a full 128 bit mask, while the eth1 should be (probably - your mileage may vary...) the 64 bit one. Otherwise you end up with 2 equal routes for the same network, one out of each interface. Very very unlikely to be what you want!!!!!)

With this I am specifying that in addition to any automatic address the interface picks up, I also want to statically assign a PREFIX+::1 address to the interface.

After the boot I inspect the results and see:

ip6 addr show dev eth0

2: eth0: mtu 1500 qlen 1000

inet6 2a01:XXX:8b25:7ea0:240:63ff:fef5:f93c/128 scope global dynamic

valid_lft 86369sec preferred_lft 86369sec

inet6 2a01:XXX:8b25:7ea0::1/128 scope global tentative

valid_lft forever preferred_lft forever

inet6 fe80::240:63ff:fef5:XXX/64 scope link

valid_lft forever preferred_lft forever

Excellent! We see the link address that was there previously. And now we have two global addresses. The one marked dynamic which is clearly the MAC-derived address (notice how the prefix is as expected – this was picked up not from any of our config but from a remotely received router advertisement from the ISP) and the one marked tentative which is as manually configured by me.

Testing

When we set up the shorewall6 firewall, everything was marked as blocked except for ipv6-icmp. Ostensibly this was to permit what we are about to do now, a ping test, which makes use of ICMP. However it was also in the knowledge that the Router Advertisements which we picked up from the ISP, and which gave us the prefix to be used for the dynamic address, are also, coincidentally, ICMP6. Two birds with one stone: we allow pings to go in and out, and also allow IPv6 Router Advertisements to pass unhindered.

So, to test our interface, let’s try something:

ping6 ipv6.google.com

PING ipv6.google.com(2a00:1450:8006::69) 56 data bytes

64 bytes from 2a00:1450:8006::69: icmp_seq=1 ttl=54 time=39.4 ms

64 bytes from 2a00:1450:8006::69: icmp_seq=2 ttl=54 time=38.4 ms

64 bytes from 2a00:1450:8006::69: icmp_seq=3 ttl=54 time=35.6 ms

It works!!

Which is great, but where’s the routing and so forth that is being used here? Let’s look at that too:

ip6 neigh show

fe80::XXX:cbff:fea5:1a68 dev eth0 lladdr 00:07:cb:a5:1a:68 router REACHABLE

That’s kind of like our IPv4 ARP table: where is, in Layer 2 terms, the next hop? And we see it at the given link address, with a corresponding MAC address, and a marker of REACHABLE. That REACHABLE can change as entries get set up and then age out, and values such as DELAY or STALE might also be seen.

ip6 route show

2a01:XXX:8b25:7ea0::/128 dev eth0 proto kernel metric 256 expires 85889sec mtu 1480 advmss 1420 hoplimit 0

fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0

fe80::/64 dev eth0 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0

default via fe80::XXX:cbff:fea5:1a68 dev eth0 proto kernel metric 1024 expires 1283sec mtu 1480 advmss 1420 hoplimit 64

Note that the default route is, automatically, via the adjacent router we learned about from the router advertisement.

ip6 monitor

192.168.0.3 dev eth1 lladdr 00:18:8b:86:f3:52 STALE

ff02::1:fff5:f93c via ff02::1:fff5:f93c dev eth0 metric 0

cache mtu 1480 advmss 1420 hoplimit 0

fe80::XXX:cbff:fea5:1a68 dev eth0 lladdr 00:07:cb:a5:1a:68 router REACHABLE

192.168.0.3 dev eth1 lladdr 00:18:8b:86:f3:52 STALE

fe80::XXX:cbff:fea5:1a68 dev eth0 lladdr 00:07:cb:a5:1a:68 router STALE

The monitor command is quite interesting. It shows the significant state changes as they occur. Here we can see IPv4 ARP entries aging out, and IPv6 neighbors becoming active and then stale.

And of course to really shine a light on what’s happening, we could do something like:

tcpdump ip6 -i eth0

…

16:00:58.856832 IP6 2a01:XXX:8b25:7ea0:240:63ff:fef5:f93c > 2a00:1450:8006::6a: ICMP6, echo request, seq 1, length 64

16:00:58.897135 IP6 fe80::207:cbff:fea5:XXX > ff02::1:fff5:f93c: ICMP6, neighbor solicitation, who has 2a01:e35:8b25:7ea0:240:63ff:fef5:f93c, length 32

16:00:58.897305 IP6 2a01:XXX:8b25:7ea0:240:63ff:fef5:f93c > fe80::207:cbff:fea5:1a68: ICMP6, neighbor advertisement, tgt is 2a01:e35:8b25:7ea0:240:63ff:fef5:f93c, length 32

16:00:58.897664 IP6 2a00:XXX:8006::6a > 2a01:XXX:8b25:7ea0:240:63ff:fef5:f93c: ICMP6, echo reply, seq 1, length 64

16:00:59.856858 IP6 2a01:XXX:8b25:7ea0:240:63ff:fef5:f93c > 2a00:1450:8006::6a: ICMP6, echo request, seq 2, length 64

16:00:59.892915 IP6 2a00:XXX:8006::6a > 2a01:XXX:8b25:7ea0:240:63ff:fef5:f93c: ICMP6, echo reply, seq 2, length 64

.
.
.

So at this point we now know that we have basic IPv6 connectivity in and out of the firewall.

Summary

What we’ve done here, after a quick recap of IPv6 addressing techniques, is to:

Enable a default “block almost everything” IPv6 firewall.
Understand the three major subsystems which might b used on an IPv6 router/firewall (dhcp6c, dhcp6s, radvd)
Understand that we possibly only need radvd and to install it on the firewall.
Assign an automatic address to our Internet-facing interface, based upon a received router advertsiement.
Assign a static address to the same interface, in addition to the automatic address.
See how we can examine IPv6 information relating to interfaces, route tables and neighbours.
Monitor IPv6 activity for troubleshooting purposes.
Do a simple ping test to confirm that we have basic IPv6 connectivity from the firewall out to the IPv6-Internet.

In the next part I will look at extending IPv6 inside the private network, and examining options for moving the VPN to a native IPv6 implementation.