This blog post is part of a series on ipv6. Part 4.0 describes requesting a Hurricane Electric tunnel; this part explains how to configure a Juniper ScreenOS firewall – SSG, ISG or Netscreen – to work with such a tunnel.
Sample environment
I am going to give an example based on ScreenOS 6.0.0 or later syntax. ScreenOS 5.4 is reported to support IPv6 6in4 tunnels, as well, though it does not expose the configuration to the web interface.
These settings can (almost) all be configured through the web interface. In the interest of brevity, I am going to show CLI commands instead.
Here are the interface names and addresses used in this example. In this example, I use the IPv6 documentation prefix. When configuring this, you get the real addresses from the Tunnel Details page.
External interface name: ethernet0/0, Untrust zone
Internal interface name: bgroup0, Trust zone
Tunnel interface name: tunnel.1, Untrust zone
Server IPv4 address: 255.254.253.252
Server IPv6 address: 2001:0db8:1:223::1/64
Client IPv6 address: 2001:0db8:1:223::2/64
Routed /64: 2001:0db8:2:223::/64
Anycasted IPv6 Caching Nameserver: 2001:0db8:1234::2
Enabling IPv6
This is the one step you must do from command line. Enter:
set envar ipv6=yes
and reboot. This will enable IPv6 features on your ScreenOS device.
Setting up the tunnel
The first step is to set up a tunnel interface that will allow you to encapsulate IPv6 packets in IPv4 packets.
set interface “tunnel.1” zone “Untrust”
set interface “tunnel.1” ipv6 mode “host”
set interface “tunnel.1” ipv6 ip <Client IPv6 address>
set interface “tunnel.1” ipv6 enable
set interface tunnel.1 tunnel encap ip6in4 manual
set interface tunnel.1 tunnel local-if <External interface> dst-ip <Server IPv4 address>
set interface tunnel.1 mtu 1480
unset interface tunnel.1 ipv6 nd nud
set interface tunnel.1 ipv6 nd dad-count 0
set route ::/0 interface tunnel.1 gateway <Server IPv6 address>
We’re creating the tunnel.1 interface, assign it to the “Untrust” zone, and give it its IP address, the “Client IPv6 address”.
Next we’re creating the tunnel itself, terminating on the external interface on one side and the Server IPv4 address on the other side.
We restrict MTU to 1480 as that is the largest packet that can go through without fragmentation, and disable Neighbor Unreachable Detection for good measure. I haven’t had issues with nud on, but others have.
Finally, create a default IPv6 route through the tunnel.1 interface, so our IPv6 traffic has somewhere to go.
Setting up IPv6 for the local network
Next, we’ll use the “Routed /64” that HE gave us for our internal network.
set interface “bgroup0” ipv6 mode “router”
set interface “bgroup0” ipv6 ip 2001:0db8:2:223::1/64
set interface “bgroup0” ipv6 enable
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 dhcp6 server
set interface bgroup0 dhcp6 server options dns dns1 <HE IPv6 Name Server>
set interface bgroup0 dhcp6 server enable
Here, we are giving the LAN interface an IPv6 address from the “Routed /64” range – in the interest of simplicity, I chose “1”. We then enable Router Advertisement so that local machines can receive IPv6 addresses from this interface.
We’re also setting the RA “other” bit and enabling DHCPv6 to give out HE’s IPv6 DNS server. Those two steps are optional: It’ll mean that Google’s IPv6-enabled services will resolve with both an IPv4 and an IPv6 address – otherwise, Google will only be reachable by IPv4.
Setting up an IPv6 firewall policy
As an example, here is a very simple policy that allows all outgoing IPv6 traffic, and denies all incoming IPv6 traffic. Adjust as fits your environment.
set policy from “Trust” to “Untrust” “Any-IPv6” “Any-IPv6” “ANY” permit
set policy from “Untrust” to “Trust” “Any-IPv6” “Any-IPv6” “ANY” deny
Thorsten on (mostly) Tech 
My 2 cents;
Great article!
set policy from “Untrust” to “Trust” “Any-IPv6″ “Any-IPv6″ “ANY” deny
I would take RFC4890 into consideration before filtering everything on the untrust interface for IPv6.
http://www.ietf.org/rfc/rfc4890.txt
Once upon a time (think CheckPoint 4.1 and older), we had to allow ICMP error notices through firewalls manually. And allow ping replies, manually. What a mess that was.
Luckily, firewall vendors wised up. These days, ICMP is handled “semi-statefully”: When imcp-echo is allowed, icmp-reply gets a “trap door” to come back in. When a TCP connection is established or a UDP packet sent, similarly, “trap doors” for ICMP error messages (host/port unreachable, et al) are opened.
It is entirely safe to filter everything on the untrust interface for IPv6, just as it is with IPv4. As a general rule with any major firewall vendor, that is. Bugs do exist: If ICMPv6 messages that should make it through do not, in fact, make it through, I’d consider that a bug and raise the issue with JTAC to get a PR created.
When I set up my tunnel, I have NUD enabled. I’m not aware of any problems up to date, but what kind of issues might I see?
If the tunnel router did not respond to NUD packets, you’d see traffic not flowing through the tunnel. Since everything’s working, you may as well leave NUD on.