Configuring an IPv6 tunnel on a netscreen SSG firewall

Submitted by Bart on Sun, 04/06/2008 - 09:57

I have a netscreen SSG firewall from which I wanted to establish a tunnel to SixXS. I tried this in the past when IPv6 support had just been added, but didn't have much luck. However, nowadays it works pretty well. I've had a working tunnel for about a year now.

The first thing to do is to get a tunnel to an IPv6 broker and request a subnet for your internal systems. Personally I use SixXS but you can probably use any broker you like. As an example, I'll be using these settings:

  • Tunnel broker ipv4 address: 127.34.8.97
  • Tunnel ipv6 address: 2001:DB8:202:123::2/64
  • ipv6 subnet used internally: 2001:DB8:8AA:1::/64

Second, start by upgrading your device to the latest available firmware. IPv6 support is constantly improving as support for more ALGs is added. If you still have a 5GT, you're stuck using 5.4 but if you have an SSG, you can upgrade to 6.0 or even 6.1.

Next, enable IPv6 support on the device. It's not enabled by default so you have to change a boot parameter and restart the device. You can only do this from the CLI:

  1. set envar ipv6=yes

After the device has rebooted, you'll see that there are a few new commands available to configure IPv6 on interfaces and use IPv6 addresses in policies. Next we'll begin configuring the tunnel to our tunnel broker. I'd recommend doing this from the CLI when you are using version 5.4 because the WebUI had some bugs back then.

  1. set interface tunnel.1 zone "Untrust"
  2. set interface tunnel.1 ipv6 mode "host"
  3. set interface tunnel.1 ipv6 ip 2001:DB8:202:123::2/64
  4. set interface tunnel.1 ipv6 enable
  5. set interface tunnel.1 tunnel encap ip6in4 manual
  6. set interface tunnel.1 tunnel local-if adsl2/0 dst-ip 127.34.8.97
  7. set interface tunnel.1 mtu 1280
  8. set route ::/0 interface tunnel.1 gateway :: preference 20

This should give you a working tunnel and allow you to ping IPv6 addresses from the netscreen itself. Next we'll assign an IPv6 address to our internal interface and configure it so that the attached systems will get an autoconfigured address:

  1. set interface ethernet0/1 ipv6 mode "router"
  2. set interface ethernet0/1 ipv6 ip 2001:DB8:8AA:1::1/64
  3. set interface ethernet0/1 ipv6 enable
  4. unset interface ethernet0/1 ipv6 ra link-address
  5. set interface ethernet0/1 ipv6 ra transmit
  6. set interface ethernet0/1 ipv6 nd nud

That should give your internal systems an IPv6 address. All that is left now is configure a policy to allow the IPv6 traffic to pass through. Configuring this is just like when you are using IPv4, except that there now isn't an object named "Any" anymore but there are two, "Any-IPv4" and "Any-IPv6".
A simple policy to allow outbound connections would be:

  1. set policy from "Trust" to "Untrust" "Any-IPv6" "Any-IPv6" "ANY" permit log

Of course, I'd recommend to make them a bit more restrictive. Be very careful with rules from Untrust to Trust. All your internal systems will have a public IP address, don't just allow everything or you might wake up one morning and find something like this:

One thing to keep in mind when you are updating your policies is that you cannot have both IPv4 and IPv6 addresses in one address group. This effectively means that you will have separate policies in your rulebase for IPv4 and IPv6, so try to keep them ordered logically.

Update sept 13, 2009
I recently set up another IPv6 tunnel, this time on a netscreen 5GT running ScreenOS 6.2r3. I decided to incorporate some of the feedback from the comments below, so that the netscreen can be pinged by SixXS for monitoring. The netscreen should respond to pings on its tunnel interface, but doesn't do so for IPv6 traffic, a bug which has been reported to Juniper but which has not yet been fixed.

So instead of putting my IPv6 endpoint address on the tunnel interface, I used a loopback interface, with a /128 subnet mask. Then I created the tunnel interface as before, but making it unnumbered, inheriting the address from the loopback interface:

  1. set interface "loopback.1" zone "Untrust"
  2. set interface "loopback.1" ipv6 mode "host"
  3. set interface "loopback.1" ipv6 ip 2001:DB8:202:123::2/128
  4. set interface "loopback.1" ipv6 enable
  5. set interface loopback.1 route
  6. set interface loopback.1 manage ping
  7. unset interface loopback.1 ipv6 nd nud
  8.  
  9. set interface tunnel.6 ip unnumbered interface loopback.1
  10. set interface "tunnel.6" ipv6 mode "host"
  11. set interface "tunnel.6" ipv6 enable
  12. set interface tunnel.6 tunnel encap ip6in4 manual
  13. set interface tunnel.6 tunnel local-if adsl2/0 dst-ip 127.34.8.97
  14. set interface tunnel.6 mtu 1280
  15. ! had to disable NUD otherwise the tunnel interface state changed to down.
  16. unset interface tunnel.6 ipv6 nd nud
  17.  
  18. set route ::/0 interface tunnel.6 gateway :: preference 20
  19.  
  20. ! note: an explicit policy is only needed when intra-zone blocking is enabled on the Untrust zone
  21. set policy name "SixXS monitoring" from "Untrust" to "Untrust"  "Any-IPv6" "2001:DB8:202:123::2/128" "ICMP6 Echo Request" permit

This works perfectly. Because my external interface IP is dynamic on this device, I set the SixXS tunnel type to Heartbeat and installed AICCU on an internal machine to keep the connection alive.

filed under
Thu, 08/28/2008 - 23:18 — Goofball (not verified)

What type of tunnel did you set up with SixXS?

I'm trying to get this same thing working with an SSG5 running ScreenOS 6.1.0r3 and was unable to get the tunnel working using Hurricane Electric as a tunnel broker with standard 6to4 manual tunnels. It always went from a ready state straight to DOWN.

I've got a SixXS account as well and was going to try a configuration on there to see if maybe it was something with HE but I have no idea what type of tunnel to create.

Is there any additional configuration you might not have posted needed to make the SSG bring the tunnel up?

Fri, 08/29/2008 - 16:02 — Bart

The tunnel type is set to "IPv6 over IPv4 manual tunneling", not 6to4.

Those commands should be all thats needed. I'd use the CLI to set up the tunnel because the webUI had some bugs in older versions and I'm not sure they have all been fixed.

Sat, 08/30/2008 - 00:47 — Goofball (not verified)

I mis-spoke when I stated it was "6to4" I meant "IPv6 over IPv4 manual tunneling".

I also don't think I was clear about what I was asking tunnel wise. I was wondering what you had set up with SixXS, a static, heartbeat or AYIYA type of tunnel. I ended up taking a chance and setting up a heartbeat tunnel with SixXS that is currently working great for me.

Also, I was able to set everything up as below via the web interface as well as the command line. It seems that Juniper has worked out many of the bugs with IPv6 and the web interface.

Your config modified to fit my addressing worked but made my SSG5 running ScreenOS 6.1.0r3 crash about every 5 minutes. Below is what I am currently running.

  1. ! Turn on IPV6 (reboot required)
  2. set envar ipv6=yes
  3.  
  4. ! Set Up Untrusted Ethernet Interface with our side of IPv6 in v4 tunnel IPv6 address
  5. set interface "ethernet0/0" ipv6 mode "host"
  6. set interface "ethernet0/0" ipv6 ip 2001:1938:XXXX:XXXX::2/64
  7. set interface "ethernet0/0" ipv6 enable
  8.  
  9. ! Set Up Tunnel Interface (Interface tunnel.2 is used in my setup because of existing VPN tunnel on interface tunnel.1)
  10. set interface tunnel.2 ip unnumbered interface ethernet0/0
  11. set interface "tunnel.2" zone "Untrust"
  12. set interface "tunnel.2" ipv6 mode "host"
  13. set interface "tunnel.2" ipv6 enable
  14. set interface tunnel.2 tunnel encap ip6in4 manual
  15. set interface tunnel.2 tunnel local-if ethernet0/0 dst-ip 209.197.5.66
  16. set interface tunnel.2 mtu 1480
  17.  
  18. ! Set default route for IPv6 traffic
  19. set route ::/0 interface tunnel.2 gateway :: preference 20
  20.  
  21. ! Set route to SixXS PoP IPv6 ip to use tunnel interface due to /64
  22. ! being configured on ethernet0/0 instead of unnumbered and non-addressable tunnel.2 interface
  23. set route 2001:1938:XXXX:XXXX::1/128 interface tunnel.2 gateway :: preference 20

Everything with this setup comes up and I can ping IPv6 hosts from the SSG5 as expected.

Sat, 09/06/2008 - 06:20 — Feren (not verified)

I just wanted to say thanks to "Goofball" for posting the relevant portions of config from his SSG-5. I signed up with SixXS a few days ago and didn't know how to go about getting my SSG-5 up and running once they'd assigned me a tunnel address. I found this page which gave me a good start but I could not get the tunnel to come up to "Ready" state (Still.... thank you, Bart, for sharing what you did!) and I was getting a bit morose until I scrolled down and saw the configuration snippets for the SSG-5 that had been posted. I followed those pretty much step-by-step, adapting for my own relevant SixXS parts, and was up and running shortly after.

I would like to ask if the /128 in the final configuration statement (for the route) is the magic sauce. I'm still trying to wrap my head around v6 network prefixes and subnet sizes so I'm not too sure. I have a /64 from SixXS and they supplied a /64 that was one above it... why the /128 route?

Thanks again for the configuration snippets from the both of you and for any insight you might see fit to share with this v6 neophyte.

-Feren

Sat, 09/06/2008 - 10:24 — Bart

Because he configured the ipv6 address on the eth0/0 interface instead of on the tunnel interface as I did, the netscreen will see his /64 as a network directly connected on eth0/0 and add a route for it. But that is wrong, it should be routed to the tunnel interface. Therefor, he added a more specific route so he can reach the SixXS POP. The /128 route is a route for just one address, similar to configuring a /32 route in ipv4.

Both approaches should work. In fact, the first time I managed to get the tunnel up and running, thats how I did it as well. But I consider my current setup to be cleaner, although it seems to be a bit more difficult to get working.

I'll pick up another netscreen from our lab next week and try to reproduce the problems others seem to be having.

Mon, 09/08/2008 - 02:44 — Frostbite (not verified)

Goofball's statements seem to work better for me. Yours make more logical sense that the /64 should be bound to the tunnel interface. However, when I do that on my 5GT-Wireless running 5.4.0r10.0, the interface never, ever comes ready; it remains Link-Down. I know Juniper says it doesn't support IPv6 on the 5GT (which is odd since it says it supports it on the 5XT, which is long since EOL'd), so I'm hoping to snag an SSG-5 from the office, put 6.1.0r3 on it, and try that.

Fri, 09/12/2008 - 17:30 — Kevin Stevens (not verified)

After working with SixxS, I see why Goofball did this. If you put the tunnel endpoint address on the tunnel interface, you can't ping it - for some unknown reason you can't execute "manage" commands on tunnel interfaces. So by moving the IPv6 endpoint address to the physical interface, it can be pinged (and thus monitored) by the tunnel broker - essential for them to know the tunnel is up.

I did the routing a bit different, I put the ::2 endpoint address on the physical interface with a /128. That automatically gives it a route entry as a connected host. Then I just set my ::/0 default route to the tunnel interface itself, with a remote gateway of the ::1 ISP tunnel endpoint. That lets me reach that address via the default route, and avoids having to make any special routing table entries to accommodate the /128 addressing. Seems to work fine!

Tx all.

KeS

Sat, 08/30/2008 - 14:25 — Bart

My tunnel type is set to static with a fixed IP specified.

I experienced crashes with 6.0r3 through 6.0r5 as well, most likely related to IPv6. But its now running stable on version 6.0r5a. Haven't tried the 6.1 releases yet, I always wait a while before switching to a new major release, especially when using special features :)

Wed, 09/10/2008 - 06:48 — Kevin Stevens (not verified)

I had the same problem with HE and my SSG, trying to instantiate a tunnel that I had no problem with using a BSD gif interface. Haven't resolved it yet. On advice from Goofball, I tried Sixxs, requested a static tunnel, and the tunnel popped right up.

I now have a different problem - AFAIK, there is no provision in ScreenOS (6.1r3) for enabling ping on a 6in4 tunnel interface. So there's no "set int tun.1 manage ping" option at all. Thus, while I can ping the POP end of the tunnel and beyond with no problem; they can't ping my end of the tunnel, and thus it shows the tunnel is down. How are y'all handling this?

Relevant config:
set interface "tunnel.1" zone "Untrust"
set interface "tunnel.1" ipv6 mode "host"
set interface "tunnel.1" ipv6 ip 2001:1938:81:21::2/64
set interface "tunnel.1" ipv6 enable
set interface tunnel.1 tunnel encap ip6in4 manual
set interface tunnel.1 tunnel local-if ethernet0/0 dst-ip 209.197.5.66
set interface tunnel.1 mtu 1420
set interface tunnel.1 ipv6 nd nud
set interface tunnel.1 ipv6 nd dad-count 0

KeS

Sun, 02/21/2010 - 17:25 — Joshua Rogers (not verified)

Following this configuration, I'm having a hard time getting 'tunnel.6' to come up. Can you clarify the purpose of the second tunnel interface, and maybe the path of traffic from host through interfaces and lookups on the SSG and then to sixxs, and back?

Sun, 02/21/2010 - 17:46 — Bart

My bad, I updated the article manually on a sunday morning and apparently made some mistakes. They have been corrected now (removed reference to second tunnel interface and set the subnet mask on the loopback to /128).

So, I only have one interface, named "tunnel.6" which is the connection to sixxs. Anything routed to this tunnel interface, gets encapsulated in an ipv4 packet and is sent to the sixxs PoP.

The trick with the loopback interface is just to get the device to respond to pings, which is used by sixxs to monitor the tunnel. If you configure an IPv6 address on tunnel.6, the netscreen won't respond to pings sent to that address.

Mon, 02/22/2010 - 05:20 — Joshua Rogers (not verified)

I see three different MTU values set. I'm guessing sixxs sets the max mtu to 1480 to make room for the IPv4 header for encapsulation. And 1280 as a default 'just to be safe', have you run into trouble with fragmentation or the SSG being able to handle fragmenting when using MTU 1280?

Tue, 02/23/2010 - 03:35 — Joshua Rogers (not verified)

you missed one:

#
set route ::/0 interface tunnel.1 gateway :: preference 20

should use tunnel.6

Tue, 02/23/2010 - 04:00 — Joshua Rogers (not verified)

Also, your statement:

>I set the SixXS tunnel type to Heartbeat and installed AICCU on an internal
>machine to keep the connection alive.

How do you keep aiccu from assigning the :2 IP to an interface on your host?

Tue, 02/23/2010 - 19:13 — Bart


How do you keep aiccu from assigning the :2 IP to an interface on your host?

Thats a bit tricky, aiccu has a "noconfigure" option but that seems to be broken. It still configures an interface named "sixxs" with the :2 address.

As a workaround, I added "defaultroute false" to the aiccu config. It still creates the interface but doesn't install a route to it. The only drawback is that this machine can't ping the ipv6 pop anymore - but that doesn't really matter.

Post new comment

  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.