m0n0wall as an IPv6 firewall

This is a guest post from Antonios Atlasis

Last October I had a quick look at pfSense 2.1 regarding the IPv6 support that it offers. It was the first stable support of pfSense that offered the capability for IPv6 network connectivity (a few comments about it can be found here). However, I knew that m0n0wall supported IPv6 quite a long time ago and that their developers had incorporated the support of IPv6 features which are not available in pfSense yet, so today I decided to have a look at it too.

The latest version of m0n0wall is version 1.8.1, released in 15th of January and it is based on FreeBSD 8.4. In this post, I am not going to explain how to configure m0n0wall to use IPv6 – this is beyond the scope of this post – but to describe briefly its security-related features regarding IPv6. By no means this is any kind of actual testing, which is going to follow at some time later as part of the  RISC project; instead, it is just a brief presentation of features.

Firewall Rules

Let’s have a look first at the options that it offers regarding the built of IPv6 firewall rules. m0nowall allows the configuration (regarding blocking/allowing, etc) of rules using one or more of the following IPv6 Extension headers:


A few notes here. First, regarding IPv6-OPTS there is no clarification if this is about the IPv6 Destination Options Extension header, the IPv6 Hop-by-Hop Extension header, or both (probably both, but I would rather prefer to have the capability to configure them independently).  As far as Routing header is concerned, there is no distinction regarding the Type (Type-0, Type-1, etc.). Finally, as we can easily observe, this is just the initial list of IPv6 Extension headers defined in RFC 2460 and it does not include any of the ones added later. Anyway, it is a good start. However, this is also the case for the commercial IPv6 firewalls that we had the chance to check during the RISC project.

If you choose to create an IPv6 rule using IPv6-ICMP, then you can specify the type of the ICMPv6 from the following options (see screenshot below):

Destination Unreachable
Packet Too Big
Time Exceeded
Echo Request
Echo Reply
Multicast Listener Query
Multicast Listener Report
Multicast Listener Done
Router Solicitation
Router Advertisement
Neighbor Solicitation
Neighbor Advertisement
Redirect Message



Another interesting observation looking at the bottom of the screenshot: You can define via a checkbox whether fragmented packets should be allowed or not. There is also an informative hint: “This option puts additional load on the firewall and may make it vulnerable to DoS attacks.In most cases, it is not needed. Try enabling it if you have troubles connecting to certain sites.
OK, as we know DoS is not the only potential security issue which can be a result of allowing fragmentation, but at least there is a security versus functionality warning. 

Firewall Logs

Since m0n0wall gives you the capability to define IPv6 firewall rules, you should obviously have the corresponding display of the logs too. And here they are, mixed with the IPv4 ones, ordered by time, as they should.


System Logs

This is what it impressed me more. Looking at the System logs, I saw some warnings about receiving Router Advertisement (RA) messages on a “wrong” (non-advertising) interface.



I am not sure if this is due to the fact that I have misconfigured m0n0wall or because my ISP sends to my WAN interface RA messages, but the fact that these are logged is definitely a positive thing from a security perspective. Some more testing (e.g. using rogue RA messages) would really show how useful such logs can be.


You have also the chance to send your Syslog logs using IPv6 and if I recall correcly from Christopher’s part of the presentation at Troopers 14, this is not the case for several commercial IPv6 appliances. So, here it is:


To Sum Up


In summary, it seems that the latest m0n0wall release, apart from the IPv6 connectivity and the various management options that it offers regarding IPv6, it also provides several security-related features, the most remarkable of which is the ability to create rules using several IPv6 Extension headers. Definitely, a more thorough testing is required, but at a first glance, it seems quite promising and that it can be a good open-source altenative solutions to commercial IPv6 router/firewalls. Due to this fact, we are aiming at examining it using the same scenarios used during the  RISC project, so stay tuned 🙂

Have a great weekend everybody,



Leave a Reply

Your email address will not be published. Required fields are marked *