Connecting the world…

juniper

Juniper SSG to Cisco ASA VPN with overlapping subnets

I needed to configure a site-to-site VPN connection between a Juniper SSG firewall and a Cisco ASA firewall. The configuration of a VPN connection is very straightforward, but this time the networks behind the firewalls are overlapping.

I have configured the Cisco ASA multiple times in such scenario, but the configuration of the Juniper SSG was new for me. I found a good article in the Juniper Knowledge Base. The article helped me to configure the VPN connection on the Juniper SSG firewall. The “tricky” part is the configuration of the MIP’s on the tunnel interface and the policy from the VPN network to the Trust network.

The only difference in my configuration is the definition of proxy ID’s within the VPN profile configuration. My scenario involves multiple subnets behind the Juniper SSG firewall en behind the Cisco ASA firewall. For every combination of subnets (Security Association) you have to configure a separate tunnel interface and VPN profile.

Upgrade Juniper SA cluster

Add On: This procedure also works for the new Juniper MAG appliances. But keep in mind during the upgrade of the second host (and also the first): BE PATIENT!!

A Juniper SA cluster can be configured as active/active or active/standby cluster. An active/active cluster uses an external load balancer or DNS round-robin to enable load-sharing across multiple appliances. Today I had to upgrade an active/standby cluster and found an KB article on the Juniper website (restricted access) about the preferred upgrade method.

Juniper uses the following steps to upgrade a cluster:

  1. 1. Login directly to a member in the cluster as administrator;
  2. 2. Disable the member from the cluster;
  3. 3. Upgrade the service package on the disabled member;
  4. 4. After the upgrade is completed login back to the IVE and enable the disabled member in the cluster configuration;

The following notes are mentioned by Juniper:

  • In active/standby cluster mode, it is recommended to start the upgrade process with the passive members and after completing the upgrade on the passive IVE and moving to the upgrade of the active IVE please note all connections are dropped when the active IVE is disabled. However after disabling the active node the passive IVE becomes active;
  • Once the upgraded member is enabled back in the cluster, it shows the other nodes as Unreachable. This is expected behavior as the cluster members are running different versions and hence cannot sync with each other;
  • Once the second IVE is being upgraded all user connections are dropped and not migrated due to the mismatch of software versions. This limitation is addressed in 4.0 with the Minimal downtime cluster upgrade available in the licensable Central Manager feature set;

I followed the steps mentioned above and the upgrade of the IVE cluster went smoothly. I disabled the passive node and upgraded the firmware with the new package. After the upgrade (and a reboot) the passive node was reachable in standalone mode. Next I logged in to the active IVE and enabled the passive node back into the cluster. When you hit Enable you receive the warning message that the configuration of the new cluster node will be erased and overwritten with the configuration of the active node. Just choose Yes.

After enabling the passive node, you will loose your web session with the active node. The VIP address is taken over by the new node in the cluster and the “old active” node starts updating automatically. This is a little tricky, because you don’t notice anything from the update process taken place. Just have patience and ping the node to check when it is online again. When the node is back online, login to the IVE and check the Cluster Status. Both IVE are now updated and members of the cluster. You could decide to do a manual Fail-Over IP to the “old active” node so everything is back to the original state before the upgrade.

GNS3 supports JunOS

A lot of you will know GNS3. GNS3 is a graphical network simulator that allows simulation of complex networks. With GNS3 you can simulate multiple Cisco routers and the Cisco PIX firewall. GNS3 allows you to emulate real Cisco IOS images, design and experiment with complex networks, connect the virtual lab to the real world and capture packets with tools like Wireshark. I often use GNS3 to test my designs for customers or use it for training and workshop purposes.

As mentioned before GNS3 only supported some Cisco routers and the Cisco PIX firewall. In GNS3 0.7RC1 the emulation of Junipers JunOS is added. Just like the emulation of the Cisco ASA firewall. This makes GNS3 even more powerful. The preparation of a JunOS image is not as straightforward as an IOS one, but GNS3 wrote this excellent article for emulating a JunOS image.

I recommend GNS3 for everyone how is playing and likes to play with Cisco routers and firewalls, and from now on also Juniper routers.

Juniper SA – Host Checker

Security is getting more and more important for people. I notice that especially IT manager would like to implement some kind of security measurements to improve the safety of their network and data. Lately I have been busy with configuring a Juniper SA solution. The customer wants to publish different kind of services through the Juniper SA to his employees or suppliers. Example of these services are file sharing and full IPSec tunnels. When using file sharing and full IPSec tunnels, the use of a virus scanner is arbitrary for all workstations connecting to the customers network through the Juniper. Juniper provides an option to configure a Host Checker to check if the client has a (specific) virus scanner. This kind of predefined check only works with Windows clients.

I wanted to configure a predefined Host Checker for all the Windows clients connecting to the Juniper SA box. The configured policy checks all Windows clients on a, by Juniper supported, virus scanner. This works perfectly, but I noticed at all Linux and Mac OS X users weren’t able to connect anymore. When configuring a Host Checker policy for Windows, you also have to configure a policy for other OS-users, like Linux and Mac OS X.

I didn’t know which policy to configure for these users, because the outcome of the policy check should be positive at all times. I have the option to check the presence of a specific file. This gave me the idea to configure a dummy file check for Linux and Mac OS X clients. The dummy file check has the following properties:

Host Check

The policy checks the presence of the file mac_dummy_file. To pass the host checker test, the file should NOT be present of the client. I configured a similar rule for Linux clients. By configuring the policy like this, all Windows clients are checked on the presence of a virus scanner and the Linux and Mac OS X hosts are checked on the dummy file. Normally, the dummy file doesn’t exist on the specific Linux / Mac OS X clients, so they are always allowed access to the Juniper.

I guess it’s a nice workaround….

Juniper SA & Terminal Service with JavaRDP

Today I tried to configure a JavaRDP as fallback Terminal Services method on the Juniper SA appliances. It took me some time and with help of my colleague, I finally got it working. Even with Single Sign On to the Terminal Server.

First of all, you need to upload a new Java applet. The Java applet I use can be downloaded here:

JavaRDP14-1.1.zip

I use the JavaRDP provided by Elusiva. After uploading the JavaRDP applet I created a custom HTML page for the JavaRDP applet, like shown below:

<html>
<head>
<title>Booches RDP Applet</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″>
</head>
<!–
Notes:
1) << CODEBASE >> is a system value that will get replaced at the time the applet is launched. Please do not modify this value.
2) Please modify the remaining values as needed.
3) Please make sure all attribute names/values are enclosed in double quotes.
–>
<body>
<applet code=”com.elusiva.rdp.applet.RdpApplet.class”
codebase=”<< CODEBASE >>”
archive=”JavaRDP14-1.1.jar”
width=”1024″ height=”768″
name=”Booches RDP” align=”top”>
<param name=”code” value=”com.elusiva.rdp.applet.RdpApplet.class”>
<param name=”codebase” value=”<< CODEBASE >>”>
<param name=”archive” value=”JavaRDP14-1.1.jar”>
<param name=”cabbase” value=””>
<param name=”name” value=”Booches RDP”>
<param name=”width” value=”1024″>
<param name=”height” value=”768″>
<param name=”align” value=”top”>
<!–
Please specify additional params here after the comment.
<param name=”paramname” value=”paramvalue”>
–>
<param name=”Server” value=”<<HOST>>”>
<param name=”Port” value=”<<PORT>>”>
<param name=”Username” value=”<<USER>>”>
<param name=”Password” value=”<<PASSWORD>>”>
</applet>
</body>
</html>

The solution works like a charm!!!