Categories

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

Sunday, 28 April 2019

Palo Alto verify VPN tunnels

.
diagnostics

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


Debugging:


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




source:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g00000

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 10.10.64.0/24

BGP

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

NAT


x




TRAFFIC LOG FILTERS


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 192.168.10.10)  searches all based on a certain source IP

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

to combine these two:


(addr.src in 192.168.10.10)  and (addr.dst in 10.10.24.100)


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


(addr.dst in 10.10.24.0/30)  

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



source:  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClSlCAK




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".


Namaste

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
2-Tomcat
3-IPSEC (used for DRF, backup)
4-CAPF
5-TVS

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

Thursday, 4 October 2018

packet capture on ASA

In order to do perform a packet capture on a Cisco ASA from the CLI, you will need to use the 'capture' command. by default the capture will use a 0.5MB buffer for a single capture session.

ON the CLI issue the capture command, enter and this will show you the current and historic captures that run/have run on the ASA.

Below are the options:

 capture Test ?

  access-list             Capture packets that match access-list
  buffer                          Configure size of capture buffer, default is 512 KB
  circular-buffer  Overwrite buffer from beginning when full, default is
                                           non-circular
  ethernet-type    Capture Ethernet packets of a particular type, default is IP
  headers-only     Capture only L2, L3 and L4 headers of packet without data in
                                          them
  interface                  Capture packets on a specific interface
  match                         Capture packets matching five-tuple
  packet-length    Configure maximum length to save from each packet, default
                                           is 1518 bytes
  real-time                Display captured packets in real-time. Warning: using this
                                           option with a slow console connection may result in an
                                          excessive amount of non-displayed packets due to performance
                                          limitations.
  trace                          Trace the captured packets
  type                            Capture packets based on a particular type


So the 3 main ones are logging against an existing access-list, against an interface or a match statement like the one below,  capturing only traffic to 192.168.31.12, similar to a Wireshark capture filter.:


capture f5test5 interface IDMZ  match ip any host 192.168.31.12


once you are happy with the capture duration, or, once you have generated test traffic, view the capture:

view capture f5test5







https://community.cisco.com/t5/security-documents/asa-using-packet-capture-to-troubleshoot-asa-firewall/ta-p/3129889


Tuesday, 2 October 2018

Dialplan, Dialpeer, Digit manipulation conundrum

A quick post on the order of digit manipulation and dial peer matching, because every time  i am tasked to configure something IOS dialplan related, I have to remind myself.

Every call across a CME, H323 gateway, CUBE or whatever, has two parts:

INBOUND CALL LEG and an OUTBOUND CALL LEG.  ALWAYS

INBOUND Dial peer matching

Inbound dial peer matching is done in the following order:
  1. Match the dialed number (DNIS) using the incoming called-number dial peer configuration
  2. Match the caller ID information (ANI) using the answer-address dial peer configuration
  3. Match the caller ID information (ANI) using the destination-pattern dial peer configuration command.
  4. Match an incoming POTS dial peer by using the port dial-peer configuration command
  5. If no match has been found using the previous four methods, use dial peer 0

Most times, to make this behavior controllable, and to catch it at the first step, particularly if there is no need for inbound digit manipulation add a dial peer like:

dial-peer voice 111111 voip
 description # Default VOIP Incoming DP #
 incoming called-number .
 voice-class codec 1

If none of your oher dialpeers have any more specific "incoming called number" statements, your dialpeer 11111 will get hit on the inbound.


OUTBOUND Dial peer matching


Digit manipulation order:





Num-exp does get hit first, it is configured globally and NOT on a dial peer level.

The second tier, is the automatic digit strip of a pots dial peer on explicitly matched digits. for example is you offer a called number of 038945666 and you have a pots dial peer with destination patter 0389..... the 0389 will get stripped, because its explicitly matched (applying no digit-stripforward digits all or prefix 0389 on the dial peer, would prevent this from happening).