IPv6-test.com and SRX firewall policies

ipv6-test.com is a useful site for testing IPv4 & IPv6 connectivity. It checks that v4 & v6 are working as expected, and reports your browser v4/v6 preferences. It does have one oddity with ICMPv6 tests. Here’s what I did to work around it with my SRX setup.

The site runs a suite of tests and gives you a score out of 20. Most dual-stack home users will probably get 17/20. They deduct 1 point for no reverse DNS entry for v6, and 2 points for “ICMP Filtered”


How can you improve your score ?

1. Reconfigure your firewall
Your router or firewall is filtering ICMPv6 messages sent to your computer. An IPv6 host that cannot receive ICMP messages may encounter problems like some web pages loading partially or not at all.

2. Get a reverse DNS record

The first one is fine, but the second issue is a worry. ICMP is a critical part of IPv6. It’s needed for things like Neighbor Discovery, and Packet Too Big messages.

Most home user firewall setups will be fairly simple. Basically ‘Allow everything out, and allow related traffic back in. Drop everything else.’ Surely the default policy on the SRX should be allowing related ICMPv6 messages back in? Let’s check some tcpdump output on our client:

We can see the destination unreachable message returned. So why does the test fail?

It’s because that page is just doing a simple echo-request. It assumes that if it can ping you, then all ICMPv6 must be allowed. This is wrong, but it was probably the simplest test to code.

If you want that test to pass, you’ll need to make some changes to your local firewall. Here’s what I added to my SRX:

My trusted zone is the internal network, and untrusted is outside the WAN interface. I didn’t have any policy in place for that direction. You can see I’ve added a new policy that matches the ICMPv6 echo-request. Now reload the IPv6-test page:


And now check the tcpdump output:

Now we can see the echo request/reply traffic.

No real difference to usability, but hey, now that test passes.


4 Responses to IPv6-test.com and SRX firewall policies

  1. Marco May 6, 2016 at 1:03 pm #

    Any guide on to change the stuff to make it work?

    • Lindsay Hill May 6, 2016 at 1:08 pm #

      The post includes the config to apply to an SRX. Are you looking for something else?

  2. Thomas Heuberger June 14, 2016 at 9:46 pm #

    I stumbled across your post by chance, and wanted to let you know that for a proper IPv6 design you should allow ALL incoming ICMPv6 packets, not just echo requests to pass a stupid web page test. v6 heavily relies on ICMPv6 working properly and not being filtered.

    So, in order for your policies to comply to RFC 2463 and RFC 4890 your policy should read:

    policy icmpv6 {
    match {
    source-address any-ipv6;
    destination-address any-ipv6;
    application junos-icmp6-all;
    then {

    and should be made a global policy.

    • Lindsay Hill June 22, 2016 at 12:26 pm #

      I agree that ICMPv6 is a critical part of an IPv6 design. But I’m not convinced that blindly allowing all ICMPv6 is the right answer – e.g. see the recent ND issues, and workarounds proposed by the various vendors. If we have a network policy of “allow that which is needed, and no more”, then why would we allow routed ND traffic?

      Overall, I think I’d rather have an approach similar to that used with v4 – i.e. allow specific ICMP types/codes as required, but not allow all types/codes by default.

      Assuming that the firewall is smart enough to handle related ICMP traffic – e.g. to know that a “packet too big” message relates to a currently active TCP session, then do we really need to allow all inbound ICMPv6 by default? What other useful message types might we be missing? (This also assumes that the firewall is allowing the necessary local ICMPv6 for ND, RA, etc)