Shrubbery.net TACACS+ daemon and Junos

14 06 2017

Axians Professional Services normally recommends using RADIUS authentication to our customers, but one of our customers uses TACACS.  We did some type-approval testing of new Junos release for them recently and had to set up a TACACS+ daemon in the lab to make sure authentication still worked following the upgrade.

Shrubbery.net very helpfully provide a TACACS+ implementation that you can download to a Linux host for this purpose, but the documentation is a bit light on their website, and what you find using Google is naturally somewhat Cisco-specific.  So here are some notes on getting a basic setup going with Shrubbery’s tac_plus daemon and Junos.  Maybe this will help someone else.

Read the rest of this entry »





Restoring Space 15.2 data to 16.1

30 01 2017

The upgrade from Space platform 15.2 to 16.1 is one of the worst procedures I’ve seen in quite a while.   It is complicated because the underlying CentOS is being upgraded at the same time, so I guess that’s part of the reason, but still, it could be a lot slicker and better tested.

In summary, you have to apply a couple of patches, the second of which backs your 15.2 data up somewhere else – ideally over SCP to a remote server.  You then shut down your 15.2 VM, install a fresh 16.1 VM with the same IP addresses, and restore the data to it.

Sounds easy, but the 16.1 installation part can generally only be done by the customer’s VMware admin because it needs console access.  So you’ve got to rely on them following lots of instructions quite well. Read the rest of this entry »





JBAS011469 Error in Junos Space

9 09 2016

Just went onto a customer’s Junos Space/Security Director installation to discover that their SRX5800 was showing as ‘out of sync’.    I tried to do a ‘Resynchronize with Network’ from the Device Operations menu, but this failed with the following error:

Error while reading config from device: <devicename> javax.persistence. TransactionRequiredException: JBAS011469: Transaction is required to perform this operation (either use a transaction of extended persistence context)
jbas011469

JBAS011469 error in Space 15.2

Unfortunately (like most Space-related errors) there’s nothing about this in Juniper’s knowledgebase – the only hit I found on a Google search was a similar error, but with a different cause that had been fixed.   So I thought I’d put this here in case it helps anyone.   Read the rest of this entry »





Junos Space Log Collector – Utilities

5 08 2016

The Juniper documentation on log collector is a bit sparse to be honest, and once it is installed, SSHing to it doesn’t seem to produce a configuration menu any more.  In order to change its config, there are some scripts, but I had to dig around for them: Read the rest of this entry »





Forgotten ‘maintenance’ password for Junos Space

30 06 2016

The maintenance users password can be reset in Junos Space if you still have access via the CLI:

  • SSH to the Space host
  • Log in as the admin user
  • Choose the debug option on the menu (6 or 7, depending on whether this is a VM or an appliance).  Just press the number, not the number followed by return!
  • Put in the admin user’s password again.  You’re now in the Centos shell.
  • Issue the command ‘htpasswd -sb /var/www/maintenance/maintPW maintenance <newpassword>

 

Simple as that…   I was never sure why an additional maintenance password was required as well as the admin user and the GUI super user password.  Makes it a pain to keep a record of, but there you go – presumably there’s a good reason.





Junos Space – checking processes are running

10 03 2016

After two miserable nights trying to upgrade Space 13.1R1.6 to 14.1R1.9,  I finally called up JTAC for some assistance.  For some reason the upgrade started, but never finished – the GUI remaining in ‘maintenance mode’ for several hours.

What they did:

Read the rest of this entry »





Junosphere – inaccessible VMXes

24 07 2015

Update:  The problem described in this article was logged with JTAC.  It took a while but eventually they informed me they had resolved an issue with provisioning VMX in the Junosphere system.  I have tried it since and the issue does appear to have gone away.  However I am leaving this post up in case it has simply become more intermittent.   Please let me know if you experience a situation like what is described below.

I usually use the ‘experimental’ VMX in my Junosphere topologies because I don’t like the VJX all that much.  The VJX has security code in it, so it’s not quite like an MX really.   Also I’ve seen oddities where it came up in flow mode with a default firewall policy of denying everything, and I was never able to work out why.

So instead I use the VMX for everything – which is better these days because it doesn’t use two VM units for the data and control planes like it used to.  Why VMX is still ‘experimental’ after so long is a mystery to me.

However one thing just keeps cropping up with this that is just a bit annoying.   Read the rest of this entry »