Juniper ScreenOS: DHCPv6 Prefix Delegation

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.

IPv6 Site-to-Site VPN Recommendations

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.)

OSPFv3 for IPv6 Lab: Cisco, Fortinet, Juniper, Palo Alto, Quagga

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.

OSPF Visualizer

While reading the OSPF chapter in the Cisco CCNP ROUTE learning guide, I was interested in how to visualize an OSPF area. Since every router in the same area has a complete view of all routers and networks, it should be easy to draw a map. So, I searched through the web for this kind of OSPF plotter and found two different approaches. While none of them worked out of the box, I was able to run one of them with an additional software router (Quagga) inside my OSPF area which finally drew a map. Yeah. Here we go:

Policy Based Routing on a Cisco ASA

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 try to give some hints within this blog post.

Policy Based Forwarding on a Palo Alto with different Virtual Routers

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.

Policy-Based Routing on ScreenOS 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:

Palo Alto High Availability Heartbeat

Beside the HA1 and HA2 interfaces on a Palo Alto Networks firewall, there are the HA1/HA2 Backup and Heartbeat Backup options. I was a bit confused while reading the documentation of the high availability instructions since it did not clearly specify when and where to use the dedicated management port for what kind of “backup”.

Basically, it should read that there are two different ways on how to use the dedicated management for a HA Backup: the heartbeat backup OR the HA1 backup.

Roundcube Installation Guide

Roundcube is an email webclient which is easy and intuitive to use. I am using it for my private mails, connecting via IMAP and SMTP to my hoster. One of the great advantages is the “flag” option which is synchronized via IMAP to my Apple devices.

Following is a step-by-step installation guide for Roundcube plus an update scenario. It is a kind of “memo for myself”, but hopefully, others can use it as well.

1&1 DSL Routing: Hop Counts unterschiedlich

Seit über einem Jahr zeichne ich die Anzahl der Hops von einer Reihe DSL-Anschlüssen auf (siehe hier). Mein Monitoring-Server läuft dabei hinter einem statischen Anschluss der Telekom, während die privaten Internetanschlüsse von diversen Anbietern (1&1, Kabel Deutschland, Telekom) kommen. Nun habe ich leider nicht im Detail die Ahnung davon, wie diese Anbieter ihren Traffic routen, zumindest scheint aber 1&1 irgendetwas Komisches bei sich verbaut zu haben, da sehr oft nach der nächtlichen Zwangstrennung ein deutlicher Unterschied in der Anzahl der Hops zu sehen ist.

Policy Routing on a FortiGate Firewall

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. 😉

IPsec Site-to-Site VPN FortiGate <-> FRITZ!Box

Hier kommt ein kurzer Guide wie man ein Site-to-Site VPN zwischen einer FortiGate Firewall und einer AVM FRITZ!Box aufbaut. Anhand von Screenshots zeige ich die Einrichtung der FortiGate, während ich für die FRITZ!Box ein Template der *.cfg Konfigurationsdatei bereitstelle.

Yet another ownCloud Installation Guide

If you want to use you own ownCloud installation, you can find several documentation on the Internet on how to set up this server, e.g. the official ownCloud documentation, or installation guides such as this or that or here. But none of these page alone provided enough information for installing a secure server completely from the beginning.

So here comes my step-by-step guide which surely won’t be complete, too. 😉 However, hopefully it will help other people while searching for their way to install ownCloud. Additionally I am showing how to upgrade an ownCloud server.

Out of the Box Network Analyzer “ntopng”

Some time ago I installed a new firewall at the customer’s site. Meanwhile the customer was interested in the flows that are traversing through the firewall right now. Oh. Good question. Of course it is easy to filter through log messages of firewalls, but theses logs are only for finished sessions. Yes, there are “session browsers” or the like on all firewalls, but they are not nice and handy to analyze the sessions in realtime.

The solution was to bring a network analyzer on a mirror port near to the firewall. I decided to use ntopng running on the live Linux distribution Knoppix. Great choice! An old notebook with two network adapters fits perfectly. A handful commands and you’re done:

F5 SSL Profile: “Single DH use” not working?

In the paper of the Logjam attack, a sentence about the F5 load balancers confused me a bit: “The F5 BIG-IP load balancers and hardware TLS frontends will reuse $g^{b}$ unless the “Single DH” option is checked.” This sounds like “it does NOT use a fresh/ephemeral diffie-hellman key for new connections”. I always believed, that when a cipher suite with EDH/DHE is chosen, the diffie-hellman key exchange always generates a new $b$ for computing $g^{b}$. Hm.

Therefore, I tested this “Single DH use” option on my lab F5 unit, in order to find out whether the same public key (as noted in Wireshark) is used for more than one session.