ScreenOS
ScreenOS is the operating system used by the Juniper SSG and NetScreen range of firewall devices (NetScreen was purchased by Juniper in 2004).
ScreenOS supports IPv6, although it is only officially supported on a subset of devices. Any Juniper SSG running ScreenOS 6 or higher should work without any issues. IPv6 is also known to work with the NetScreen 5GT (Running ScreenOS 5 or 6) and a few other pre-ScreenOS 6 devices. To see if your device works with IPv6 simply type the following command into the cli and then reboot the device:
set envar ipv6=yes
If your device supports IPv6 you will be able to assign an IPv6 address to an interface (Please note that the web interface doesn't always show this and you may need to use the cli)
The first step in getting IPv6 to work through SixXS is to sign up for an account. Once your account has been approved you will then need to request a tunnel. Once you tunnel is active you can start setting up the NetScreen.
Contents
Setting Up an IPv6 Tunnel
Updated November 17th 2013, based on a working config I built on an SSG5 using this blog as a reference.
N.b. Unlike most other configuration on a ScreenOS based device, an IPv6 tunnel cannot be setup using the web-interface, because you cannot select the ip6in4 encapsulation (and probably other things too).
Step 1. Create a loopback interface
It's perfectly possible to terminate the tunnel on a regular tunnel interface. However, tunnel interfaces do not reply to ICMPv6 Echo (ping) requests, so your tunnel would fail the latency test and would be offline after 7 days.
Using a loopback interface, your end of the tunnel replies to pings sent by the SixXS POP for latency / uptime check.
set interface "loopback.1" zone "Untrust" set interface "loopback.1" ipv6 mode "host" set interface "loopback.1" ipv6 ip [Your IPv6]/128 set interface "loopback.1" ipv6 enable set interface loopback.1 route set interface loopback.1 manage ping unset interface loopback.1 ipv6 nd nud
Step 2. Create a tunnel interface
Now you can define the tunnel interface and bind it to your loopback interface. This assumes that your internet connection is on ethernet0/0. On larger SSG devices, if you have e.g. an ADSL PIC, your "local-if" interface would be adsl2/0.
N.b. My tunnel is called tunnel.2, because I have an autokey IKE VPN on tunnel.1
set interface tunnel.2 ip unnumbered interface loopback.1 set interface "tunnel.2" ipv6 mode "host" set interface "tunnel.2" ipv6 enable set interface tunnel.2 tunnel encap ip6in4 manual set interface tunnel.2 tunnel local-if ethernet0/0 dst-ip [SixXS POP IPv4 Address] set interface tunnel.2 mtu 1280 unset interface tunnel.2 ipv6 nd nud
Step 3. Create a route and configure your local subnet
First set your route. After you set this, you should be able to ping any public IPv6 address from the SSG device. If not, define an intra-zone policy from untrust to untrust that allows "ICMP6 Echo Request" from any to any (I used the web-interface for that).
set route ::/0 interface tunnel.2 gateway :: preference 20
Next, configure a subnet on your internal interface. If your configuration is standard, your internal interfaces will probably be grouped together in bgroup0.
unset interface bgroup0 ipv6 ra link-address set interface bgroup0 ipv6 ra preference high set interface bgroup0 ipv6 ra other set interface bgroup0 ipv6 ra transmit set interface bgroup0 ipv6 nd nud set interface bgroup0 ipv6 nd dad-count 0 set interface "bgroup0" ipv6 mode "router" set interface "bgroup0" ipv6 ip [(A /64 slice of) your SixXS IPv6 subnet]/64 set interface "bgroup0" ipv6 enable
Step 4. Allow outbound IPv6 traffic
You should create a policy to allow all or some traffic to the outside world on IPv6. In its simplest form, something like:
set policy from "Trust" to "Untrust" "Any-IPv6" "Any-IPv6" "ANY" permit
Done!
Your computers on your local LAN should now get an IPv6 address out of your subnet. Also, you should be able to browse the IPv6 internet, if your DNS servers serve AAAA addresses (I believe most do).
Known Issues
ICMP screening
Enabling screening for 'Large ICMP packets' will break Path MTU Discovery and block IPv6 Destination Unreachable messages. Make sure that this 'feature' is turned off. This is not only a problem for tunnels but for all IPv6 configurations!
