CUC (6) CUCM (28) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (3)

Wednesday, 20 November 2019

Solarwinds SQL queries

Sometime you will just have to go into the Solarwinds Orion DB to do certain queries, that cannot be done through the solarwinds GUI. In this post i will describe a number of queries that have helped me in the past to achieve various bits and pieces. to do these queries, open the data base manager on your solarwinds box and add the default server, the select SolarwindsOrionDatabase.

Finding interfaces in UNKNOWN Status

I needed to do this query to summarise interfaces in unknown status, that were orphaned from the actual node, and that were not visible when doing a rediscovery of the particular node, simply because the interfaces (logical) had been removed and solarwinds had not cleaned up the DB for whatever reason

Select InterfaceID, NodeID, Caption, interfacename, Status, StatusLED From [dbo].[Interfaces]
Where StatusLED = 'Unknown.gif' 


To delete any of these interfaces, you need the interfaceID (above) and run:

delete from Interfaces where InterfaceID=953insert into DeletedInterfaces (InterfaceId) values (953)

Monday, 26 August 2019

VentraIP using SCP for file transfers

Okay, this turned out to be a bit of a bitch.

I have a hosting account with VentraIP, recently VentraIP did some upgrades on their front end and as a result a feauture that I always used did no longer work:

FTP to and from my own hosting partition. after some mucking around I got file transfer to work with scp. here is how:

1-log onto your VIP control panel and got to MY services > Hosting > Manage :

2-Go to Configuration > SSH access and whitelist your own IP address (use www.ipchicken to find out),  now please note this whitelist only lasts 28 days, so you have to keep redoing it.  Also note Ventra allows a non standard port of 2683 

The username, can also be found in the cpanel under Special FTP accounts.

I have used WinSCP to connect to my ventraIP hosting partition, using the details as depeicted above. 

Anyone have any new insights on how to achieve this: please drop me a line

Sunday, 28 April 2019

Palo Alto verify VPN tunnels


Tunnel configuration check

First thing to check is probably the tunnel definition/configuration itself. use the following command to find a summary of all tunnels defined on your PA:

show running tunnel flow all

This will show you local and remote peer address, name, state, tunnel if and tunnel ID. once you know the tunnel ID you can find that tunnels configuration details as follows:

IPSEC tunnel details
This is an example of tunnel ID 27. showing the peer addresses and the protected traffic, you can also see the tunnel is in INIT state meaning it has not been established.

one of the most power full commands is the show vpn ike-sa.  This will show you phase 1 and 2 SA's:

What this also shows is, that your tunnel is up, what encryption it uses, authentication, DH groups, integrity checks etc.

You can drill down to see the individual tunnel details, using:

show vpn ike-sa detail gateway <name>

check logs:

the log for phase 1 negotiation can be found as, its probably best to turn debugging on befgore you chech the logs:

less mp-log ikemgr.log

This log will show mismatches in the proposal and or pre shared key


debug ike global on debug

This will give insight and details in the negotiations of phase 1.
If the tunnel does  not establish, this is probably the first thing to debug.

To view the debug output:

less mp-log ikemgr.log

debug ike pcap on   (debug ike pcap off to TURN the debug OFF again)

after you turn the debug off, to view the actual pcap:

view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap

verify IPSEC using

show vpn flow / show vpn flow name <name>

this command will show all the encryption parameters, peer IP addresses, and most importantly, the number of encapsulated and decapsulated bytes, so you can verify if the tunnel functions in both directions.
Other Useful CLI commands:

> show vpn ike-sa gateway <name>
> test vpn ike-sa gateway <name>
> debug ike stat


Tuesday, 23 April 2019

Palo Alto CLI cheat sheet


Routing (general)

To view the complete routing table of a certain virtual router:

show routing fib virtual-router <name of virtual router>

To view a specific route on a certain virtual machine:

 show routing fib virtual-router outer-vr | match <subnet/mask>

to verify how a certain subnet is routed:

show routing route virtual-router outer-vr destination


To view bgp peers on a certain virtual router:

show routing protocol bgp loc-rib peer ?

to find out routes receive from a specific BGP peer and you have multiple BGP peers on a single virtual router. first find out which peers exist and what their names are by issuing:

show routing protocol bgp loc-rib peer <peer-name> ?

this should give you a list of BGP peer names/IP addresses. so this allows you to pick the one you are intersted in and issue:

show routing protocol bgp peer virtual-router outer-vr peer-name Azure_2_bgppeer

show routing protocol bgp peer virtual-router outer-vr




Knowing how to apply filters in traffic logs is imperative, to cut through a whole bunch of logged information. Some useful ones are

(addr.src in  searches all based on a certain source IP

(addr.dst in   searches all based on a certain destination IP

to combine these two:

(addr.src in  and (addr.dst in

you dont have to search based on a host IP address, you can also use a full subnet, for instance:

(addr.dst in  

If you use userID based filtering, you can search the log, for instance on user ID and potentially blocks against this user:

(user.src eq 'mydomain\johndoe')  and ( action eq deny)

To search based on port:

(port.dst eq 22)  

searches for all traffic on tcp/22

again this can be combined with and additional search filter using a single host for instance


Wednesday, 2 January 2019

Configuring 2FA on Cisco IOS devices

1-Create a Networks device group 

Administration > Network Resources > Network Device Groups , Call it 2FA-Devices 
This is nothing more than a grouping, so 2FA can be applied to all devices in the group.

2-Create an external Radius token identity source

Work Centres > Device Administration > Ext ID sources

this is basically the part where you point ISE to you MFA provider, could be Azure MFA, could be Symantec VIP, Duo or whatever else is out there.

First you configure the port and IP address and shared secret of the external source (make sure connectivity is permitted, if you have a firewall in the path), so ISE can actually communicate with the external source. I have called the external source "EGW"; external gateway.  Most external MFA sources will need to have the IP address of your ISE box(es) explicitly allowed to  be able to communicate with it.

3-Create a 2FA policy set

Work Centres > Device admin Policy sets > Add

As you can see in the picture above, I am pointing the default authentication policy to "EGW". to use the previously added MFA external source. Also as you can see in the picture above, the condition is that this Policy set needs to be applied to devices in the group "2FA-devices".


Sunday, 11 November 2018

Regenerate certificates on CUCM

Quick post on what to do when your certificates on cucm are about to expire, and when you have set up your cert monitor, you will get swamped with email alerts.

To check what certificates are expiring, go to cucm > OS administration > Security > Certificate management.

There are two types of certificates: self-signed and signed by a CA.  From a security point of view you should not use self signed certificates.  When installing CUCM, the certificate store gets populated with self signed certs, with a 5 year expiry period. In my experience,  usually  all but the tomcat certs are self signed. Which makes life a lot easier when regenerating new certs. There are a couple of types of certificate types:

1-Call Manager
3-IPSEC (used for DRF, backup)

As said, there is a big chance all these need to be regenerated because they were generated at the same time: during install.

The most important thing to keep in mind is to never regenerate both Callmanager.pem and TVS.pem certificates at the same time.  I suggest the following order, that served me well a couple of times:

1) Regenerate the CallManager.pem certificate on the publisher Call Manager followed by restart of CallManager, TVS and TFTP service on PUB

2) Regenerate the CallManager.pem certificate on the subscriber Call Manager followed by restart of CallManager, TVS and TFTP service    and repeat for every SUB in your cluster.

Steps 1 and 2 are impacting because restarting call manager service cause phones to fail over.
As a test after you performed steps 1 and 2, go to the certificate store and verify if all call managers now contain the newly regenerated certificate in their store. Note: there is no need to manually import certs, because replication will sync the certs between the call managers. Of course step when using CA signed certs, in step two, you will need to create a CSR, have it signed and import the cert back into ONLY the server on which the CSR was generated.

3) Regenerate the TVS.pem certificate followed by restart of TVS and TFTP service on the publisher Call Manager.

4) Regenerate the TVS.pem certificate followed by restart of TVS and TFTP service on the subscriber Call Manager

5) Regenerate the CAPF.pem certificate on the publisher CM server followed by regenerating it on the subscriber CM and then restart CAPF service only on publisher CM.

6) Regenerate the tomcat certificate on publisher Call Manager followed by regenerating it on the subscribers server as well

7) Restart the Cisco Tomcat on publisher Call Manager followed by subscriber Call Manager

8) regenerate IPSEC .pem on publisher, restart C: utils service restart Cisco DRF Local AND C: utils service restart Cisco DRF Master, then regenerate on SUBS  (restart DRF from SSH Console).

There is really not much to it, just follow the steps in the order above, and restart the services. When I do changes like this I keep RTMT open and monitor the registration of the phones while I go through then changes; Good luck

Thursday, 11 October 2018

F5 Big IP SAML configuration IdP

This post will discuss how you can configure your F5 Big-IP as a SAML identity provider (IdP).

In order to use your Big-IP as an IdP, there are 3 main parts to the configuration work:

1-configure Local IdP services
2-Configure external service Provider (SP) connectors.
3-assign SAML to the access policy

The External SP connectors (point 2),  are used so external services (such as, for instance Office 365, Webex or Sales Force) can successfully redirect the client that wants to access its services,  to the F5 to allow the User/client to connect to whatever server it needs to connect to.

Before I dive into the configuration part, below is a schematic representation of what SAML looks like.

Fig.1 SAML schematics
SAML is like an authentication proxy. For example you hit a web site, https, and it requires a log in, when that webpage is configured for SSO, it needs to know what(IdP) can actually do the authentication and echo the result on the SP's behalf. So essentially the IdP does all the hard work here, all the SP does is redirects the client to the IdP for authentication and if successful, the IdP will redirect the client back to the SP.

So this post will focus on the right hand part of the picture, the configuration and on how SAML requestors are allow to connect to the IdP to receive an assertion for future single sign on.  so Lets start.

On your Big-IP, go to Access Profile > SAML > BIG-IP as IdP.

1-Create the IdP

Fig.2. IdP General settings

the IdP entity ID is basically a URL that allows and SP to connect to that same URL/ID

Because SAML heavily relies on HTTP, it uses SSL for server authentication. So in the initial communications between SP and IdP, the IdP will sign the assertion (see Fig.1.) with its private key which the SP know how to decrypt using the IdP's public cert/key. (see below in Figure 3)

Fig.3. IdP security settings

So yeah, time to upload, some certs. remember, if you use like Cloud service SP's to use your on premise  F5 Big IP IdP to connect to, these certs will need to be  signed by a trusted CA, not your internal CA!!!

Next you need to configure the Assertion (see fig.4):

Fig.4 Assertion settings

These SAML assertions are key to single sign on, and contain security information, such as authentication state, security attributes and authorization. The assertion is sent from the IdP to the SP and contain security statements based on which the SP can make an access control decision on the access attempt of the client.

2 Create the SAML SP Connector

Of course the IdP is  no good just sitting there, of course SP's will need to be able to connect to is to obtain an assertion. on the other hand you dont just want every thing and every body to be able connect to it to perform proxy authentications.  So in short every SP that requires SAML to the IdP on the F5, will need to be explicitly defined. F5 call this External SP Connectors (they can be organization internal as well, they are called external because the are external to the device itself).
There are 3 key points the Big-IP will need to know in order to actually communicate with the external SP:

  1. the external SP Entity  ID, this is a URL that the SP presents when sending the GET to request a assertion from the IdP
  2. Assertion Consumer Service, also a URL
  3. the F5 will require the CA signed certificate of the SP in its certificate store. This to allow SSL to be set up and to allow the SP to authenticate itself against the IdP. 

Point 1 can be configured under General settings:

Point 2 can be configured under Endpoint settings:

Point 3 can be configured under Security settings:

Basically when the user first time tries to log into the SP, the SP actually redirects the login attempt to the IdP. after that is successful, the IdP sends an assertion to the SP and the SP send an authentication successful response to the client. (see Fig.1).

3-Use SAML in your access policy

In this part, we have to point the SP to the IdP that we configured in part 1 (name=saml_idp) to the access policy.

Fig. 5. Pointing the SP to the IdP
For this, you go to the access policy configuration under the "SSO/Auth Domains" tab you can point to the previously added IdP. (see Fig. 5).

To see this in the visual policy editor it would look something like this:

Here you have 2 types of authentication (Kerberos and web auth), split up in 3 AD groups; all using SAML.

To get a  better understanding of SAML, I suggest you install for instance the Chrome SAML tracer extension, which provides an indept insight of the contents of SAML  POST and GET messages, for example, where the IdP assertion is shown. To way to get is is to install the SAML tracer chrome extension  and then sping up the developers tools in your chrome browser (ctrl+shift+I) and go to the SAML tab, the pull up the sso website and you will see the assertions/SAML tokens

I know there is much more to write about SAML and I might in the future, but I wanted to focus on its configuration on the Big-IP's. Namaste