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 save 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 http://www.sixxs.net/tools/grh/ula/
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:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
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 ipv6.google.com PING ipv6.google.com(2a00:1450:8004::93) 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
You must be logged in to post a comment.