Until now I generated all SSHFP resource records on the SSH destination server itself via ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:
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.
Just for fun some more VPN throughput tests, this time for the late Juniper ScreenOS firewalls. I did the same Iperf TCP tests as in my labs for Fortinet and Palo Alto, while I was using six different phase1/2 proposals = crypto algorithms. The results were as expected with one exception.
I still like the Juniper ScreenOS firewalls such as the SSG 5 or the SSG 140. However, they are End of Everything (EoE) and not used at the customers anymore. But they still do their job in basic networking (static/dynamic routing such as OSPF & BGP, IPv6, NAT), basic firewalling (access policies), and IPsec VPN. Hence I am using a couple of SSGs in my lab when playing with routing protocols and so on.
After a factory reset of those firewalls there are some default settings such as zones at a few interfaces and default IP addresses. Therefore I put the following commands together in order to cleanup the default config to have only IP addresses and default routes which is a good starting point for lab configurations. Let’s go:
Yes I know, ScreenOS is “End of Everything” (EoE). However, for historical reasons I am still managing many Netscreen/ScreenOS firewalls for some customers. Similar to my troubleshooting CLI commands for Palo Alto and Fortinet I am listing the most common used commands for the ScreenOS devices as a quick reference / cheat sheet. These are only the commands that are needed for deep troubleshooting sessions that cannot be done solely on the GUI.
Since a few weeks I am using Tufin SecureTrack in my lab. A product which analyzes firewall policies about their usage and their changes by administrators (and much more). Therefore, the first step is to connect the firewalls to SecureTrack in two directions: SSH from SecureTrack to the device to analyze the configuration, as well as Syslog from the device to SecureTrack to real-time monitor the policy usage.
This blog post shows the adding of the following firewalls into Tufin: Cisco ASA, Fortinet FortiGate, Juniper ScreenOS, and Palo Alto PA.
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.
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.
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:
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. Even other tunneling methods such as Teredo or SixXS are found on different literatures. However, another method that is not often explained is to tunnel the IPv6 packets through a 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 is how I did it with some Juniper SSG firewalls:
Since IPv6 gets more and more important, I am using it by default on all my test firewalls, which of course support IPv6. However, when comparing the different functions and administration capabilities, they vary significantly.
Here comes my short evaluation of the IPv6 functions on the following four firewalls: Cisco ASA, Fortinet FortiGate, Juniper SSG, and Palo Alto.
Here comes the step-by-step guide for building a site-to-site VPN between a FortiGate and a ScreenOS firewall. Not much to say. I am publishing several screenshots and CLI listings of both firewalls, along with an overview of my laboratory.
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.
Finally, this is how I am monitoring my Juniper ScreenOS SSG firewalls with MRTG/Routers2. Beside the interfaces (that can be built with cfgmaker) I am using my template in order to monitor the CPU & memory, count of sessions & VPNs, count of different kind of attacks, etc.
Ich habe bei mir zu Hause die AVM FRITZ!Box als alleinigen Router abgelöst und durch eine Juniper SSG 5 Firewall ersetzt. Die FRITZ!Box ist trotzdem noch vorhanden und steht als IP-Client hinter der Firewall, primär um die Internettelefonie zu 1&1 bereitzustellen. Leider hat es etwas gedauert, bis ich die richtigen Einstellungen herausgefunden hatte, damit die Telefonie auch wirklich in beide Richtungen funktionierte.