If you’re following my blog you probably know that I am using IPv6 everywhere. Everything in my lab is dual-stacked if not already IPv6-only. Great so far.
A few months ago my lab moved to another ISP which required to change all IP addresses (since I don’t have PI space yet). Oh boy! While it was almost no problem to change the legacy IPv4 addresses (only a few NATs), it was a huge pain in the … to change the complete infrastructure with its global unicast IPv6 addresses. It turned out that changing the interface IPv6 addresses was merely the first step, while many modifications at different services were the actual problem. And this was *only* my lab and not a complex company or the like.
Following you find a list of changes I made for IPv6 and for legacy IP. Just an overview to get an idea of differences and stumbling blocks.
Continue reading IPv6 Renumbering: A Pain in the …
I migrated an old Juniper SSG ScreenOS firewall to a Palo Alto Networks firewall. While almost everything worked great with the Palo (of course with much more functionalities) I came across one case in which a connection did NOT work due to a bug on the Palo side. I investigated this bug with the support team from Palo Alto Networks and it turned out that it “works as designed”. Hm, I was not happy with this since I still don’t understand the design principle behind it.
However, it was a specific and not business critical case: One Palo Alto firewall with two ISP connections using a destination network address translation (DNAT, an old IPv4 problem) and policy based forwarding (PBF) with the same destination ports. Following are some more details:
Continue reading Palo Alto PBF Problem
I really love ping! It is easy to use and directly reveals whether the network works or not. Refer to Why Ping is no Security Flaw! (But your Friend) and Advanced Tracerouting. At least outgoing pings (from trust to untrust) should be allowed without any security concerns. However, many companies are denying these ICMP echo-requests from untrust into the DMZ which makes it difficult to test whether all servers are up and running.
I was sitting at the customer’s site replacing the DMZ firewall. Of course I wanted to know (from the outside) whether all servers are connected correctly (NAT) and whether the firewall permits the connections (policy). However, ping was not allowed. Therefore I used several layer 7 ping tools that generate HTTP, DNS, or SMTP sessions (instead of ICMP echo-requests) and revealed whether the services (and not only the servers) were running. Great!
This post shows the installation and usage of httping, dnsping, and smtpping on a Linux machine, in my case a Ubuntu server 14.04.4 LTS, as well as some Wireshark screenshots from captured sessions. Finally, a pcap file can be downloaded that shows the sample runs of all three tools.
Continue reading Advanced Ping: httping, dnsping, smtpping
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.
Continue reading FortiGate Virtual IPs without Reference
On the FortiGate firewall, address objects and virtual IPs (VIPs) can be set up with an interface. For address objects this has no technical relevance – the address objects simply only appear on policies if the appropriate interface is selected. But for virtual IPs, this setting has relevance on how connections are NATed. This can be problematic.
Continue reading FortiGate Virtual IPs with Interface “Any”
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.
Continue reading Policy Based Routing on a Cisco ASA
This guide is a little bit different to my other Policy Based Forwarding blog post because it uses different virtual routers for both ISP connections. This is quite common to have a distinct default route for both providers. So, in order to route certain traffic, e.g., http/https, to another ISP connection, policy based forwarding is used.
Continue reading Policy Based Forwarding on a Palo Alto with different Virtual Routers
I already puslished a blog post concerning policy-based routing on a Juniper firewall within the same virtual router (VR). For some reasons, I was not able to configure PBR correctly when using multiple VRs. Now it works. ;) So, here are the required steps:
Continue reading Policy-Based Routing on ScreenOS with different Virtual Routers
This is a small example on how to configure policy routes (also known as policy-based forwarding or policy-based routing) on a Fortinet firewall, which is really simple at all. Only one single configuration page and you’re done. ;)
Continue reading Policy Routing on a FortiGate Firewall
MIP DIP VIP. I am sometimes confused with the NAT names of the Juniper ScreenOS devices. Therefore, I drew a small figure with a few basic examples for these NAT types.
Continue reading Juniper ScreenOS NAT Overview: MIP DIP VIP
I am using a Cisco router for my basic ISP connection with a NAT/PAT configuration that translates all client connections to the IPv4 address of the outside interface of the router. Furthermore, I am translating all my static public IPv4 addresses to private ones through static NAT entries. I basically thought, that only the IPv4 addresses in the mere IPv4 packet header would be translated. However, this was not true since I immediately discovered that public DNS addresses are translated to my private IPv4 addresses, too. This was a bit confusing since I have not explicitly configured an application layer gateway (ALG) on that router.
“Google is my friend” and helped me one more time to find out the appropriate solution: The “no ip nat service alg udp dns” keyword to disable the DNS rewrite. (The synonym from Cisco for DNS rewrite is: DNS doctoring.) Here comes a basic example:
Continue reading Cisco Router: Disable DNS Rewrite ALG for Static NATs
Here comes an example on how to configure policy-based routing (PBR) on a Juniper ScreenOS firewall. The requirement at the customers site was to forward all http and https connections through a cheap but fast DSL Internet connection while the business relevant applications (mail, VoIP, ftp, …) should rely on the reliable ISP connection with static IPv4 addresses. I am showing the five relevant menus to configure PBR on the ScreenOS GUI.
[UPDATE] I later on wrote an article with policy-based routing with two different virtual routers
. See it here
Continue reading Policy-Based Routing (PBR) on a Juniper ScreenOS Firewall
This is a small example on how to configure policy based forwarding (PBF) on a Palo Alto Networks firewall. The use case was to route all user generated http and https traffic through a cheap ADSL connection while all other business traffic is routed as normal through the better SDSL connection. Since I ran into two problems with this simple scenario, I am showing the solutions here.
[UPDATE] I also wrote an article about policy based forwarding with two different virtual routers
on the Palo Alto firewall. See it here
Continue reading Policy Based Forwarding (PBF) on a Palo Alto Firewall
During my job I am frequently discussing with people why they use NAT or why they believe that NAT adds any security to their networks, mainly some obscurity as NAT (PAT) hides the internal network structure. However, NAT does not add any real security to a network while it breaks almost any good concepts of a structured network design. To emphasize this thesis, here is a discussion:
Continue reading Why NAT has nothing to do with Security!