Just a few days ago I gave a talk at Troopers 18 in Heidelberg, Germany, about the problems of dynamic (non-persistent) IPv6 prefixes, as well as IPv6 VPNs in general. Following are my slides and the video of the talk:
And one more IPsec VPN post, again between the Palo Alto Networks firewall and a Fortinet FortiGate, again over IPv6 but this time with IKEv2. It was no problem at all to change from IKEv1 to IKEv2 for this already configured VPN connection between the two different firewall vendors. Hence I am only showing the differences within the configuration and some listings from common CLI outputs for both firewalls.
Towards the global IPv6-only strategy ;) VPN tunnels will be used over IPv6, too. I configured a static IPsec site-to-site VPN between a Palo Alto Networks and a Fortinet FortiGate firewall via IPv6 only. I am using it for tunneling both Internet Protocols: IPv6 and legacy IP.
While it was quite easy to bring the tunnel “up”, I had some problems tunneling both Internet Protocols over the single phase 2 session. The reason was some kind of differences within the IPsec tunnel handling between those two firewall vendors. Here are the details along with more than 20 screenshots and some CLI listings.
With PAN-OS version 8.0 Palo Alto Networks introduced another IPv6 feature, namely “NDP Monitoring for Fast Device Location“. It basically adds a few information to the existing neighbor cache such as the User-ID (if present) and a “last reported” timestamp. That is: the admin has a new reporting window within the Palo Alto GUI that shows the reported IPv6 addresses along with its MAC addresses. This is really helpful for two reasons: 1) a single IPv6 node can have multiple IPv6 addresses which makes it much more difficult to track them back to the MAC address and 2) if SLAAC is used you now have a central point where you can look up the MAC-IPv6 bindings (comparable to the DHCP server lease for legacy IPv4).
Haha, do you like acronyms as much as I do? This article is about the feature from Palo Alto Networks’ Next-Generation Firewall for Internet Protocol version 6 Neighbor Discovery Protocol Router Advertisements with Recursive Domain Name System Server and Domain Name System Search List options. ;) I am showing how to use it and how Windows and Linux react on it.
And finally the throughput comparison of IPv6 and legacy IP on a Juniper ScreenOS firewall. Nobody needs this anymore since they are all gone. ;) But since I did the same speedtests for Palo Alto and FortiGates I was interested in the results here as well.
After I have done some speedtests on the FortiGate firewall I was interested in doing the same tests on a Palo Alto. That is: What are the throughput differences of IPv4 vs. IPv6, measured with and without security profiles, i.e., with and without threat prevention.
It turned out that the throughput is much higher than the official information from Palo Alto. Furthermore, I was not able to test the threat prevention at all, because non of my traffic (Iperf and mere HTTP) went through the antivirus engines. I have to test this again. However, here are the measured values so far:
The most common transition method for IPv6 (that is: how to enable IPv6 on a network that does not have a native IPv6 connection to the Internet) is a “6in4” tunnel. Other tunneling methods such as Teredo or SixXS are found on different literatures as well. However, another method that is not often explained is to tunnel the IPv6 packets through a normal VPN connection. For example, if the main office has a native IPv6 connection to the Internet as well as VPN connections to its remote offices, it is easy to bring IPv6 subnets to these stations. Here comes an example with two Palo Alto firewalls.
I was interested in the performance of my FortiGate firewall when comparing IPv4 and IPv6 traffic. Therefore I built a small lab consisting a FortiWiFi 90D firewall and two Linux clients running Iperf. I tested the network throughput for both Internet Protocols in both directions within three scenarios: 1) both clients plugged into the same “hardware switch” on the FortiGate, 2) different subnets with an “allow any any” policy without any further security profiles, and finally, 3) activating antivirus, application control, IPS, and SSL inspection.
It’s really great that the FortiGate firewalls have a DHCPv6 server implemented. With this mandatory service, IPv6-only networks can be deployed directly behind a FortiGate because the stateless DHCPv6 server provides the DNS server addresses. (This is unlike Palo Alto or Cisco which have no DHCPv6 server implemented.)
However, the configuration on the FortiGate is really bad because nothing of the IPv6 features can be set via the GUI. (And this is called a Next-Generation Firewall? Not only the features count, but also the usability!) Everything must be done through the CLI which is sometimes hard to remember. Therefore I am publishing this memo of the appropriate CLI configuration commands.
I am lucky to have a full dual-stack ISP connection at home. However, the ISP only offers a dynamic IPv6 prefix with all of its disadvantages (while no single advantage). In this post, I am summarizing the limitations of a dynamic prefix and some of the ideas on how to overcome them. I am always comparing the “IPv6 dynamic prefix” state with the legacy “dynamic IPv4 address” situation. I suppose that some of these problems will hit many small office / home office locations during the next years.
Of course, IPv6 ISP connections with dynamic prefixes should only be purchased at private home sites. It is no problem to have new IPv6 addresses there because all connections are outbound. However, many small remote offices (SOHO) might rely on such cheap ISP connections, too. If they provide some servers in a DMZ or other components such as network cameras, building components with IPv6 connections, etc., they will run into these kind of problems. (The remote office could even tunnel every outbound IPv6 traffic through a VPN to the headquarter. But if it wants to use a local breakout, this won’t be an alternative.)
How to route traffic inside an IPv6 site-to-site VPN tunnel if one side offers only dynamic IPv6 prefixes? With IPv4, the private network segments were statically routed through the tunnel. But with a dynamic prefix, a static route is not possible. That is, a dynamic routing protocol must be used. Here is an example of how I used OSPFv3 for IPv6 between my VPN endpoints.
In detail, I have a home office with a dual stack ISP connection. However, this connection has a dynamic IPv6 prefix: After every reboot or lost connection of the firewall, I get a new IPv6 prefix. This is really bad for building a site-to-site VPN to the headquarter. Since I don’t want to use any kind of NAT/NPTv6 with unique local addresses, I am talking OSPFv3 over the VPN tunnel in order to route the dynamic prefix range (global unicast) via the tunnel.
The Juniper ScreenOS firewall is one of the seldom firewalls that implements DHCPv6 Prefix Delegation (DHCPv6-PD). It therefore fits for testing my dual stack ISP connection from Deutsche Telekom, Germany. (Refer to this post for details about this dual stack procedure.)
It was *really* hard to get the correct configuration in place. I was not able to do this by myself at all. Also Google did not help that much. Finally, I opened a case by Juniper to help me finding the configuration error. After four weeks of the opened case, I was told which command was wrong. Now it’s working. ;) Here we go.
With global IPv6 routing, every single host has its own global unicast IPv6 address (GUA). No NAT anymore. No dirty tricks between hosts and routers. Great. Security is made merely by firewalls and policies. Site-to-site VPNs between partners can be build without address conflicts. Great again!
However, one problem to consider is the proper IPv6 routing via site-to-site VPNs since both sides now can reach each other even without a VPN. This was (mostly) not true with IPv4 in which both partners heavily relied on private RFC 1918 addresses that were not routable in the Internet. If specific IPv6 traffic should flow through a VPN but does actually traverse the Internet, it would be easy for a hacker to eavesdrop this traffic, leading to a security issue!
The following principles should be realized properly to assure that IPv6 traffic is never routed through the mere Internet when a site-to-site VPN tunnel is in place. Even in a failure of that tunnel. The principles can be applied to any IPv6 tunnels between partners, remote sites, home offices, etc., as long as the other site has its own global unicast IPv6 address space. (For VPNs in which a sub-prefix from the headquarters prefix is routed to a remote site, the situation behaves different. This article focuses on the routing between different IPv6 adress spaces.)
Similar to my test lab for OSPFv2, I am testing OSPFv3 for IPv6 with the following devices: Cisco ASA, Cisco Router, Fortinet FortiGate, Juniper SSG, Palo Alto, and Quagga Router. I am showing my lab network diagram and the configuration commands/screenshots for all devices. Furthermore, I am listing some basic troubleshooting commands. In the last section, I provide a Tcpdump/Wireshark capture of an initial OSPFv3 run.
I am not going into deep details of OSPFv3 at all. But this lab should give basic hints/examples for configuring OSPFv3 for all of the listed devices.