Configuring NAT66 on ScreenOS

I recently had to deploy redeploy an old NetScreen 5GT to segregate a production LAN and create a small lab network. The production LAN has a routable IPv6 /64 prefix, delivered via a Hurricane Electric IPv6 tunnel. The lab network also required IPv6 connectivity. We also recently obtained a /48 prefix from Hurricane Electric, so I could have just assigned a /64 from that to the lab network and routed it via the 5GT. However, this 5GT gets moved around to various different networks, including trade show networks. As such, the untrust interface of the 5GT needed to be auto-configuring, so that it would obtain an IPv6 prefix from router advertisements on whichever LAN it was connected to. This also meant that assigning a /64 from our Hurricane Electric /48 prefix was out of the question.

The first step is to enable IPv6 support on your device, if it isn’t already:

set envar ipv6=yes
reset save-config yes

After restarting your device, you should find that IPv6 configuration options are available, and the web UI will also have additional pages and config options.Next, we want to configure the untrust interface as IPv6 “host” mode, and permit it to accept router advertisements from your existing upstream IPv6 router.

set interface untrust ipv6 mode host
set interface untrust ipv6 enable
set interface untrust ipv6 ra accept

The untrust interface should configure itself with an address in the prefix advertised on your existing LAN, and create a default IPv6 route (::/0) via your upstream router.

ns5gt-> get int untrust
Interface untrust:
  description untrust
  number 1, if_info 88, if_index 0, mode route
  link up, phy-link up/full-duplex
  status change:1, last change:11/09/2011 15:55:40
  ipv6 is enable/operable, host mode.
  ipv6 operating mtu 1472, learned mtu 1472
  ipv6 Interface-ID: 0210dbfffe680eb1
  ipv6 fe80::210:dbff:fe68:eb1/64, link local, PREFIX
  ipv6 2001:470:xxxx:xxxx:210:dbff:fe68:eb1/64, global aggregatable, PREFER, AUTO-CONF
  ipv6 ff02::1:ff68:eb1(2), solicited-node scope
  vsys Root, zone Untrust, vr trust-vr
  dhcp client enabled
  PPPoE disabled
  admin mtu 0, operating mtu 1472, default mtu 1500

ns5gt-> get route
IPv6 Dest-Routes for <trust-vr> (3 entries)
  ID                                IP-Prefix  Interface                  Gateway  P  Pref  Mtr  Vsys
*  3                                     ::/0  untrust   fe80::226:88ff:fe45:8242  D  252     2  Root
*  4                  2001:470:xxxx:xxxx::/64  untrust                         ::  C  0       0  Root
*  5 2001:470:xxxx:xxxx:210:dbff:fe68:eb1/128  untrust                         ::  H  0       0  Root

We can see above that the untrust interface has assigned itself an address in our Hurricane 2001:470:x:x/64 prefix. Note also that it has lowered the MTU to 1472, as advertised by our perimeter SRX. The PPPoE encapsulation of our VDSL connection incurs 8 bytes overhead, and since it is an IPv6 tunnel, we have to subtract another 20 bytes to ensure that we don’t send fragmented packets via Hurricane (who seem to drop fragmented traffic).

The next step is to configure the trust interface of the 5GT. I tend to use policy NAT, rather than the often-configured default of interface-NAT. Note that if you have existing outbound policies that were depending on the interface being in NAT mode, you will need to adjust those policies to perform source address NAT.

set interface trust route

Enable IPv6 on the trust interface in “router” mode. First we should generate a RFC 4193 Unique Local Address (ULA). SixXS offers an online tool to generate one of these pseudo-random, quasi-unique prefixes from a MAC address at

An address from a ULA prefix has a global scope, however the fc00::/7 prefix is filtered by ISPs, so there is no chance of these addresses colliding on the Internet. The pseudo-random prefix generation is simply to minimise the chance of a prefix collision on a LAN. The SixXS tool will generate a /48 prefix for you; choose a /64 prefix from that, and assign it to the trust interface:

set interface trust ipv6 mode router
set interface trust ipv6 ip fd61:b452:a23d::1/64
set interface trust ipv6 enable

Enable IPv6 router advertisements from the trust interface:

set interface trust ipv6 ra link-address
set interface trust ipv6 ra transmit

If your MTU is less than 1500 on the untrust side, you should also advertise it on the trust side:

set interface trust mtu 1472
set interface trust ipv6 ra link-mtu

At this stage, you should be able to connect a host to the trust side of the 5GT and acquire an IPv6 address from the fd61:b452:a23d::/64 prefix.

[root@smurfette ~]# ifconfig
eth0      Link encap:Ethernet   HWaddr D0:27:88:65:21:B5   
          inet addr:   Bcast:   Mask:
          inet6 addr: fd61:b452:a23d:0:d227:88ff:fe65:21b5/64 Scope:Global
          inet6 addr: fe80::d227:88ff:fe65:21b5/64 Scope:Link

Now we just need to create a NAT policy for our IPv6 traffic. If you had any existing “IP any/any” policies, setting the envar “ipv6=yes” should have converted those policies to “Any-IPv4” policies. Create a policy for your IPv6 traffic:

set policy from "Trust" to "Untrust" "Any-IPv6" "Any-IPv6" "ANY" nat src permit

At this point, you should be able to ping from your trust-side host to a host on the untrust-side, and beyond:

[root@smurfette ~]# ping6 2001:470:xxxx:xxxx::1
PING 2001:470:xxxx:xxxx::1(2001:470:xxxx:xxxx::1) 56 data bytes
64 bytes from 2001:470:xxxx:xxxx::1: icmp_seq=1 ttl=63 time=3.48 ms
64 bytes from 2001:470:xxxx:xxxx::1: icmp_seq=2 ttl=63 time=2.52 ms

[root@smurfette ~]# ping6 -n
PING 56 data bytes
64 bytes from 2a00:1450:8004::93: icmp_seq=1 ttl=53 time=43.9 ms
64 bytes from 2a00:1450:8004::93: icmp_seq=2 ttl=53 time=44.2 ms

So there it is… the 5GT is performing NAT66 on the fd61:b452:a23d::/64 prefix to the globally routable 2001:470:xxxx:xxxx::/64 prefix, using the source address of the egress (untrust) interface. Using this technique, we can connect this 5GT to any IPv6-enabled LAN, and connect hosts behind the safety of our own firewall, whilst still having outbound IPv6 connectivity.





Leave a Reply