Migrating from Juniper ScreenOS firewalls to FortiGates, there are some differences to note with static NATs, i.e., Mapped IPs (MIPs) on a Netscreen and Virtual IPs (VIPs) on a FortiGate. While the Juniper MIPs on an interface are always used by the firewall whenever a packet traverses the interface, the virtual IP objects on a FortiGate must be used at least once in the security policy before they are really used by the firewall.
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.)
Cisco ASA 9.4 (and later) is now supporting Policy Based Routing. Yeah. Great news, since many customers are requesting something like “HTTP traffic to the left – VoIP traffic to the right”. Coming with a new Cisco ASA 5506-X I was happy to try the policy based routing feature.
The configuration steps through the ASDM GUI are not easy and full of errors so I am trying to give some hints within this blog post.
When working with Cisco devices anyone knows that the output of a “show running-config” on one device can be used to completely configure a new device. On a Palo Alto Networks firewall, this is not that obvious. There are several commands that must be used to achieve the same.
However, I tested this procedure a few times and it did NOT work. :( So, the short version is: If you want to replace a Palo Alto firewall, move your configuration files (xml) through the GUI or tftp/scp. But do not use the mere CLI.