Syslog Watcher

Syslog Watcher :

Syslog Server
A syslog server collects, parses, stores, analyses, and explains syslog messages to professional network administrators, helping to improve the stability and reliability of the network.

Syslog Watcher installs a dedicated syslog server, integrating log data from multiple network devices into a single, easily manageable and accessible place. Collecting and analysing syslogs is essential for maintaining network stability and auditing network security.

SNMP Soft’s “Syslog Watcher” is an excellent SYSLOG server for home and commercial use.

Features and options that make it a great contender when it comes to Syslog and SNMP. The interface is and simple and intuitive, with an up-front view of all the configuration options and tasks you would want to quickly perform. The server can be started and stopped, status can be pulled, logs can be managed and retrieved, servers can be required, events can be filtered and searched, imported and exported, reports can be fun, and so forth.

Compatibility it works well in windows server versions, 2008 and 2012, both initial and R2 versions.

On the downside, this portion of the program is somewhat lacking when it comes to customization – the overall look of it is very plain and can be hard to sort through visually without taking the time to apply filters and perform searches. By no means is it a deal breaker, but it does make it a bit harder to use “at a glance” than some other offerings. None the less, the main window provides a great deal of the information one would want to see, with a handy tabbed setup for easily jumping between different subsections of that data.

As far as a general list of features, Syslog Watcher has a log to brag about. For being a smaller and lower-cost program, it can handle upwards of 5000 Syslog messages per second, and runs as a Windows service, making it better for server-less or small-server environments.

Data and archiving are handled automatically, with more critical messages being kept longer to avoid removing important log information in favour of a rush of less important messages, thus helping reduce signal to noise ratio substantially in histories.
Thankfully, a little testing is easy to do with the personal version without any real risk of cost, and thankfully via the import/export, it’s not very hard to ramp up from the personal version into the more appropriate Standard or Pro versions that your environment might demand.


Cisco Ikev2 L2L VPNs

VPNs are amongst the most annoying topics for me. While the theory and concepts are easy the amount of moving parts required to enable it to work are easily misplaced. It doesn’t help that Cisco hasn’t found a smooth way to bring these moving parts into one section similar to how they use address-family or in routing protocols or C3PL in QoS. Instead the configuration is spread about with a piece of phase 1 over here and phase 2 over there. It doesn’t help either that ASAs and routers naming conventions are different and Ikev1 and Ikev2 parameters have different names.

Anyway, i present a minimum configuration required to allow a site-to-site (L2L / Lan To Lan) VPN to work

Reading this article is recommended before getting started.


1. Defining interesting traffic – Selected traffic creates the VPN session when called

access-list VPNACL extended permit ip


2. IKE phase 1 – Authenticate peers and setup security association in preparation for phase 2 data transfer

crypto ikev2 policy 1
encryption aes-256
integrity sha256
group 20
prf sha256
lifetime seconds 3600

! encryption [select] - encrypts data 
! integrity [select] - ensure from correct peer
! group [select] - encryption and integrity
! prf [select] - random key generator
! lifetime seconds [select] - session lifetime


2. IKE phase 2 – Add encryption and integrity to the data being transferred

crypto ipsec ikev2 ipsec-proposal PROPOSAL1
protocol esp encryption aes-256
protocol esp integrity sha-256
! protocol esp encryption [select] - encryption level
! protocol esp integrity [select] - integrity level


3. IKE phase 2 – Authentication method and keys

tunnel-group type ipsec-l2l
tunnel-group ipsec-attributes
ikev2 remote-authentication pre-shared-key cisco
ikev2 local-authentication pre-shared-key cisco


4.  Tie it all together with a crypto map

crypto map CMAP 2 match address VPNACL
crypto map CMAP 2 set peer
crypto map CMAP 2 set ikev2 ipsec-proposal PROPOSAL1


5. Enable Ikev2 and CMAP on the outside interface

crypto map CMAP interface outside
crypto ikev2 enable outside


How to verify it all works:

show crypto isakmp sa
show crypto ipsec sa

Testing multicast with VLC Media Player

Follow this document on how to setup multicast on Cisco routers:

We will focus only on VLC Media Player as a multicast source and receiver.

  1. Setup multicast network with windows 10 machines on both ends (1x receiver + 1 x server) Linux should be okay also but I was unable to receive with Debian 8. Testing was minimal so feel free to check it out yourself.
  2. permit VLC to send traffic with a TTL higher than 1. This has frustrated many including myself. You will spend a lot of time setting up your multicast network and troubleshooting it thinking you’ve done something wrong or you have some issue with your software. By default VLC uses TTL as 1 and the first router will drop the packet.


Open VLC, select “Tools > Preferences > Show settings > All8


Select “Access output” and change the TTL from “-1” to any reasonable number between 1 and 255 (100 is enough)



Select file to stream



Select “RTP/MPEG Transport Stream” and click “Add”2


Enter your multicast address you wish to stream to. You can leave the base port and stream name as default



Default transcoding settings should be fine. Change if needed



IMPORTANT!! Add “ttl=50” Change “50” to whatever number you would prefer but it must be enough hops to traverse your network. Each hop reduces TTL by 1

Note: This MUST be done in addition to the settings in VLC preferences

Press the “stream” button




Your stream will start but no video will be shown locally on the server with default settings. This is OK!



On the client / receiver. Select open stream from the media menu and enter as below


Change to match your multicast address and port



That’s it. just make sure you verify the TTL was changed via wireshark if it doesn’t work.

if TTL shows as changed in wireshark (higher than 1) then something is wrong with your multicast setup.

Need multiple loopbacks on IOS/IOU?

Use this TCL script.

  1. Change “20” in the line {$i <= 20} to match desired amount of loopbacks
  2. Change the ip range to your what you need.
  3. Copy and paste the entire script

for { set i 0 } {$i <= 20 } { incr i } {
puts [ ios_config “interface loopback$i” “ip address 169.254.$i.1” ]
sh ip int br

F5 LTM Encrypted Cookie Insert Persistence

The purpose of a load balancer is to distribute client connections to multiple servers to increase load capacity and provide high availability. One common requirement of load balanced applications, since most application servers maintain session information on the local box, is that a client must stay locked to a single server for the duration of the session. The ability of a load balancer to keep a client locked to the same server is known as persistence.

Note: An application can overcome the session persistence issue if it is architected to store session data in a centralized database of some sort. However, most applications are not designed this way.

One popular persistence method for HTTP traffic on the F5 LTM is cookie insert. Cookie insert is when the load balancer adds a session cookie to the clients session. With every request the client makes, it sends this cookie which the load balancer decodes to determine which server to send the client to. To understand this a little more, let’s look at a client request and server response from an F5 with cookie persistence. This is a capture from HTTPwatch with the client request on top and the server response on the bottom –


The client request was the first request to the server and does not have the cookie. Because of this the F5 inserts the persistence cookie in the response outlined in red. For the rest of this browser’s session it will put this cookie in each request as shown below –


The cookie insert method is one of the best for HTTP because the client will have this cookie until the browser is restarted. Source IP on the other hand will time out after 180 seconds (by default) if no packets are sent.

Cookie Insert Information Leakage

While cookie insert is a great persistence method, the default settings create some security issues with information leakage. The default F5 cookie has the following format –

BIGipServer<pool name> =<coded server IP>.<coded server port>.0000

The cookie tells us the following information –

  • BIGipServer – We now know that the server is behind an F5 BigIP device.
  • <pool name> – The name of the pool as configured on the F5.
  • <coded server IP> – The real IP of the server with a simple encoding method.
  • <coded server port> – The real port of the server with a simple encoding method.

As you can see quite a bit of information is leaked from this cookie. If you have penetration testing performed on your applications, the default cookie insert profile will show up as a security finding. The encoding method used for the server IP and port is a very simple method that can be easily decoded (you can find more information about encoding in the link at the end of the article). Using a decoding program I wrote in perl (also at the end of this article) you can gather this information from the cookie –

The persistence cookie decoded:

Plugging the Information Hole

Fortunately the F5 can be configured to not reveal this information. The first item will we tackle is the cookie name.

Changing Cookie Name
The default cookie name of BIGipServer<pool name> can be changed by creating a custom cookie persistence profile. To create the custom profile navigate to the menu as shown below –


In the New Persistence Profile, set the following settings as shown –


The settings should be –

  • Name – Something that makes sense.
  • Cookie Name – Check the custom box and enter a cookie name that does not conflict with any existing cookie names the application might use.

To apply this new profile, find your virtual server and click on the edit resources section in the virtual server list as shown –


Then select the cookie persistence profile just created as the default profile –


Now let’s take a look at the server response –


As we can see the cookie name has changed as set in the profile and no longer has the pool name either. However, the server IP and port are still in the same format.

Encrypting the Cookie
The session cookie’s contents can be encrypted with a custom HTTP profile. To create the profile navigate to the window as shown –


In the Create New HTTP profile section set the fields as shown –


Change the settings as follows –

  • Name – Something that makes sense.
  • Encrypt Cookies – Check the custom box and enter the exact name you gave the cookie in the custom persistence profile.
  • Cookie Encryption Password – Check the custom box and enter a unique password.

Now you must go back to your virtual server and apply the custom HTTP profile you created –


Let’s double check the cookie by looking at a new server response –

ef_profile_header4You can now see that the persistence cookie contents have been encrypted. The encryption cipher used is AES which by itself would turn it into a binary blob. The blob is then base64 encoded to make it compatible with a text protocol such as HTTP.

Your server info is no longer revealed.



Cookie Decode Perl Script –

use strict;
use warnings;

my ($ip,$port) = split(‘.’,$ARGV[0]);
#Convert to IP to hex
my $ip_hex = sprintf(“%x”,$ip);
#Prepend extra 0 if hex value is only 7 char
$ip_hex = “0”.”$ip_hex” if (length $ip_hex ==7);
#Decode hex to IP
my $d_ip = join (‘.’,map {hex $_} reverse ($ip_hex =~ m/../g));
#Decode hex to port
my $d_port = hex join(“”,reverse( sprintf(“%x”,$port) =~ m/../g) );

print “The persistence cookie decoded: $d_ip:$d_portn”;

Usage:  ./ 335653056.20480.0000

References –
F5 SOL6917: Overview of BIG-IP persistence cookie encoding
F5 SOL 7784: Overview of cookie encryption

Edit: Updated perl script due to errors with 7 character hex strings.

AnyConnect Certificate Based Authentication.

In order to acomplish the AnyConnect authentication using certificates the AnyConnect client should get a valid certificate from the CA server, at the

same time the ASA should have the CA Root certificate in order to properly validate the certificate of the connecting client.

1.bmp1-) Make sure you have an AnyConnect image applied in the ASA firewall:

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Client Software

Click the Add button, and browse the flash for the proper image (optionally you can upload the client from the local PC).



2-) Enable anyconnect in the outside interface:

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles

Check the box “Enable Cisco AnyConnect VPN Client or legacy SSL Client”

Then select the interface where the AnyConnect clients will be connecting to (in this example the outside interface).


The ” Allow user to select connection profile” check option will allow the AnyConnect user to select the group they will be connecting to.

3-) Create a new AnyConnect connection profile:

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles

Click the Add button, the “AnyConnect connection profile” window will open.

Give the connection profile a name and optionally a group alias.

Click the “Select” button next to the “Client Address Pools” option.

The ” Select Address Pools” window will appear.

Click the “Add” button in order to create a new pool of addresses.



4-) Create a Group-policy:

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles

Click the “Manage” button  next to the “Group Policy” option in the connection profile.

Click the “Add” button in order to create the new policy.

Give the policy a name (In this example “AnyConnect-Policy”) and check the “Clientless SSL VPN” and “SSL VPN Client” boxes, then click the “ok” button.


The AnyConnect group have been created at this point.

5-) Install the CA certificate in the ASA:

The CA certificate must be downloaded from the CA server and installed in the ASA.

Complete these steps in order to download the CA certificate from the CA server.

Perform the web login into the CA server CA-server with the help of the credentials supplied to the VPN server.


Click Download a CA certificate, certificate chain or CRL in order to open the window,

as shown. Click the Base 64 radio button as the encoding method, and click Download CA certificate.


Save the CA certificate with the certnew.cer name on your computer.


Go to Configuration > Remote Access VPN > Certificate Management > CA Certificates in the ASA firewall.

Click on the “Add” button, the “Install Certificate” window will open.

Click the “Browse” button next to the “Install from a file” option.

Browse to the location where you saved the CA certificate, highlight the CA certificate and click on the “Install” button.


At this point the CA certificate will be installed in the ASA fiwall and it willl be able to validate the connecting users, which user’s certificate was created from the same CA server.

6-) Go back to the AnyConnect connection profiles and change the profile to use certificate authentication:

Configuration > Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles

Highlight the “AnyConnect-group” profile and click the “Edit” button.

The “Edit AnyConnect Connection Profile” will open, then you will be able to select the authentication method to be “Certificate”


Click the “OK” button and then click “Apply”

(Remember to save the configuration performed)


7-) The next step would be to install the certificate in the AnyConnect client PC:

The user will need to log in into the CA server with his credentials.


Once in the CA server, the user will need to click in the “Request a certificate” option.


The user will want to select the “User Certificate” option.


At this point the CA sever will provide the user certificate to be installed.


Once the certificate is installed the user will be able to connect the AnyConnect client authenticating with the previously installed certificate

(No username and password required)



Understanding NAT and NAT Rule Order (ASA 8.3+)


Understanding NAT and NAT Rule Order (ASA 8.3/8.4

First of all, there is no such thing as ‘nat-control’ any more so you either define a NAT or you don’t. Traffic that does not match any NAT rules will be allowed to bypass the firewall without any translation (like NAT exemption but without explicitly configuring it, more like an implicit NAT exemption). The  static and global keywords are deprecated, now its all about ‘nat’.

In ASA 8.3 and above, Cisco has come up with two ‘major’ categories/sections of NAT; Manual NAT and Auto NAT. In Cisco’s documentation they have used the terms Twice NAT and Network Object NAT respectively, but in the show command’s output NAT rules are classified under Manual and Auto.

Manual NAT (Twice NAT):

It is done in the global configuration mode and can NAT based on either the source IP, the destination IP or both. This is the most preferred Section of NAT. Cisco refers this as Twice NAT in their documentation (being called as Twice NAT does not necessarily mean having the properties of Twice NAT). The NAT rules belonging to this Section are found in the Section 1 of the NAT rule table. Any type of NAT rule configured using the Manual NAT/Twice NAT syntax will be preferred over a NAT rule configured using the Auto NAT/Network Object NAT syntax, provided it is for the same source host/subnet.

Example of a Manual NAT command syntax:

asa(config)# object network private_ip
asa(config-network-object)# host
asa(config-network-object)# object network public_ip
asa(config-network-object)# host
asa(config-network-object)# exit
asa(config)# nat (dmz,outside) source static private_ip public_ip

Auto NAT (Network Object NAT):

This is done inside an object and performs NAT based on the source IP only. Cisco calls this as Network Object NAT in their documentation. This is the second preferred Section of NAT. These NATs are found in the Section 2 of the NAT rule table. Any type of NAT rule configured using the Auto NAT/Network Object NAT syntax will be less preferred over a NAT rule configured using the Manual NAT/Twice NAT syntax, provided it is for the same source host/subnet.

Example of an Auto NAT command syntax:

asa(config)# object network private_ip_1
asa(config-network-object)# host
asa(config-network-object)# nat (dmz,outside) static

Manual NAT (with less preference):

Manual NAT again takes the 3rd Section, only this time its for a different purpose. As you might have understood that Manual NAT is preferred over Auto NAT, this Section of NAT helps you to alter that behavior. If you configure a Manual NAT and want it to be less preferred over an Auto NAT, then while creating it mention that this would be applied after the Auto NAT Section, thus placing such NAT rules in the 3rd Section.

Example of a Manual NAT after-auto command syntax:

asa(config)# object network private_ip_2
asa(config-network-object)# host
asa(config-network-object)# object network public_ip_2
asa(config-network-object)# host
asa(config-network-object)# exit
asa(config-network-object)# nat (dmz,outside) after-auto source static private_ip_2 public_ip_2

Static NAT/PAT, Dynamic NAT/PAT and Identity NAT can be configured either as a Manual NAT or an Auto NAT depending upon the requirement. But Policy NAT can be configured only using the Manual NAT because of it’s flexibility.

Below is the verification command showing the NAT rule order and the terms that are used to classify the NATs in different sections depending on the syntax used to configure it.

ciscoasa#show nat interface dmz detail
 Manual NAT Policies (Section 1)
1 (dmz) to (outside) source static private_ip public_ip
 translate_hits = 0, untranslate_hits = 0
 Source - Origin:, Translated:
Auto NAT Policies (Section 2)
1 (dmz) to (outside) source static private_ip_1
 translate_hits = 0, untranslate_hits = 0
 Source - Origin:, Translated:
Manual NAT Policies (Section 3)
1 (dmz) to (outside) source static private_ip_2 public_ip_2
 translate_hits = 0, untranslate_hits = 0
 Source - Origin:, Translated:

Section 2 and Section 3 have a Static NAT rule that is for the same Source IP. By now you might have guessed which one is going to be used, right?

Yes, the one under Auto NAT because Section 2 is always preferred over Section 3. The sections are aligned in the order of their preference which cannot be modified, but you can change the order sequence of the NAT rules underneath the sections according to you requirement.

Access-control lists:

While configuring your ACLs, make sure you use the Real-IP/Pre-translated IP in them.

Inbound ACLs Pre 8.3:

access-list outside_access_in permit extended ip any host log

Inbound ACLs Post 8.3:

access-list outside_access_in permit extended ip any host log

That’s pretty much it on this topic. Hope this has been informative