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.
I am monitoring an (old) SA-2000 cluster of Juniper Secure Access devices with my MRTG/Routers2 system. With the JUNIPER-IVE-MIB I built the configuration file for that monitoring system. In this blog post, I show the graphs generated with MRTG/Routers2 and publish my cfg file as a template.
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.
For a beginner, the configuration of a J
uniper Secure Access SA/MAG Pulse Connect Secure device is not that simple. There are too many options and links that must be filled in. Though there are quite detailed configuration guides I was missing a “quick start” figure to see which profiles, roles, etc. must be set in order to have a simple login and group membership environment.
Here comes my at-a-glance poster for the Pulse Connect Secure SSL-VPN gateway.
I tested OSPF for IPv4 in my lab: I configured OSPF inside a single broadcast domain with five devices: 2x Cisco Router, Cisco ASA, Juniper SSG, and Palo Alto PA. It works perfectly though these are a few different vendors.
I will show my lab and will list all the configuration commands/screenshots I used on the devices. I won’t go into detail but maybe these listings help for a basic understanding of the OSPF processes on these devices.
I had strange looking DHCP packets in my network as I tested around with DHCP relays on the Juniper SSG firewall. Some packets were blocked and I didn’t know why. After some troubleshooting it was clear that the checkmark “Use xy Zone Interface as Source IP for VPN” has a big impact in all environments even without the usage of a VPN!
Short step-by-step screenshot guide for an initial configuration of NSRP on two Juniper ScreenOS firewalls, such as the SSGs. One screenshot pack for the https GUI and another one for the Network and Security Manager (NSM) since I am always searching for the positions of the commands on it. Finally, I am listing the appropriate CLI commands.
I was a bit confused today as I saw a “wrong” route entry in the config of an SSG firewall. The route had not the correct “network/netmask” notation but a “host-address/netmask-of-the-network” notation. However, the SSG autocorrected this false route entry to the correct subnet id in its routing table.
And finally: A route-based VPN between a Juniper ScreenOS SSG firewall and a Cisco router with a virtual tunnel interface (VTI). Both sides with tunnel interfaces and IPv4 addresses. Both sides with a real routing entry in the routing table. Great. ;)
(The VPN between those two parties without a tunnel interface on the Cisco router is documented here. However, use the route-based VPN where you can. It is easier and more flexible. Routing decisions based on the routing table. This is how it should be.)
Short and very specific notice: How to remove the exclamation marks on the Juniper NSM device list for firewalls that have an outdated attack database version. This happens if the license for the deep inspection expires and the device still has an old sigpack version. Since the NSM later on has newer ones, it marks the firewall with a yellow symbol. To have a consistent “green” view of all firewalls, the following steps can be done to remove the exclamation mark.
Similar to all my other site-to-site VPN articles, here are the configurations for a VPN tunnel between a Juniper ScreenOS SSG firewall and a Cisco IOS router. Due to the VPN Monitor of the SSG firewall, the tunnel is established directly after the configuration and stays active all the time without the need of “real” traffic.
I am using the policy-based VPN solution on the Cisco router and not the virtual tunnel interface (VTI) approach. That is: No route is needed on the router while the Proxy IDs must be set on the Juniper firewall. (However, I also documented the route-based VPN solution between a ScreenOS firewall and a Cisco router here.)
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.[/UPDATE]
This post describes the steps to configure a Site-to-Site VPN between a Juniper ScreenOS firewall and the Cisco ASA firewall. With the correct IKE and IPsec parameters as well as the correct Proxy IDs on both sides, the VPN establishment works without any problems. And since the Juniper firewall can ping an IPv4 address on the remote side through the tunnel (VPN Monitor), the VPN tunnel is established by the firewalls themselves without the need for initial traffic.
Hier kommen die Einstellungen die nötig sind, um ein Site-to-Site VPN zwischen einer AVM FRITZ!Box und einer Juniper ScreenOS Firewall herzustellen. Neben einigen Anleitungen im Netz habe ich selber ein paar Einstellungen getestet, um eine möglichst detaillierte *.cfg Datei zu haben. Außerdem ist erfreulicherweise anzumerken, dass die Juniper auch ein statisches VPN zu einer dynamischen Adresse erlaubt und somit sogar beide Seite einen Verbindungsaufbau initiieren können. Mit dem VPN Monitor von Juniper wird der Tunnel konstant “up” gehalten.
For a quick documentation on how to build a Site-to-Site IPsec VPN tunnel between a Palo Alto Networks firewall and a Juniper ScreenOS device I am listing the configuration screenshots here.
It is quite easy because both firewalls implement route-based VPNs. That is: The tunnel must not be configured with Proxy IDs or the like. It is simply built upon the correct parameters for IKE and IPsec. The related traffic can then be routed into the tunnel afterwards. And since the tunnel monitor from the Palo Alto firewall triggers the tunnel to be built even though no real traffic flows through it, the admin immediately sees green status bubbles in the GUI and can be sure that the tunnel establishment was successful. Continue reading IPsec Site-to-Site VPN Palo Alto < -> Juniper ScreenOS