Redirect HTTP to HTTPS – Citrix Netscaler

This will redirect all HTTP traffic to a virtual host to your HTTPS responder. It will save you having to handle it within the webserver.

1. Create a virtual server configuration, call it something like SERVICE HTTPtoHTTPS Redirect listening on port 80

2. Create a placeholder service with a bogus IP, like – disable health monitoring

3. Create a Responder policy, call it HTTPSRedirect with the Expression of True

4. Create a Responder action, call it HTTPSRedirect. Attach it to the Responder policy, and set the target of the action to be:


Just as a backup, I like to add in the Redirect URL of the Virtual Server config to redirect to the https URL of your destination. This covers you if the placeholder service failed for whatever reason.

Remember to configure your placeholder service to not have the default low limitations on concurrent connections/requests otherwise it’ll throttle your redirects.


Networking, Windows Server 2008 R2

Port forward/proxy/redirect – Windows – Just like Xinetd.

So, if you have an issue where you need to forward a port to a different location with Windows, you’re in luck. Whilst you don’t have xinetd, you don’t have to use a third party tool or service.




If you cannot directly route SYSTEM A to SYSTEM C but need to hit a service running on port 25/tcp on SYSTEM C from SYSTEM A, you can use portproxy. Let’s say both sides can hit SYSTEM B. You can use portproxy to set up SYSTEM B to forward your request to SYSTEM C, yet access the same service from SYSTEM A by hitting SYSTEM B.

Simply at the command prompt on SYSTEM B, type:


interface portproxy

add v4tov4 listenport=25 connectaddress= connectport=25 protocol=tcp

This means when you now hit on port 25, you’ll receive the data from SYSTEM C’s socket. Simple port proxying or forwarding.

You can also do this from IPv4 to v6, or v6 to v6.
Best of all, you can use DNS names.. !!

Simply add this in as a startup script via a group policy object, and you’ve got your own cross-network router for specific ports.

Port Proxy documentation at Microsoft:


Reset Cisco Catalyst 3750 Password

  1. Connect your console cable to the switch. 9600/8n1.
  2. Hold down the mode button on the front (underneath the LEDs to the left of the ports) of the switch and plug the power cable in. Hold it like this until you see the SYST LED go solid for a second (or just change blinking pattern) – this takes maybe 15-20 seconds. Let go of the mode button and you should see the SYST LED blink faster.
  3. Look back over at your terminal, you should see a “switch:” command prompt and some informational text, if so, enter the following commands in order (with enter between):
  4. flash_init
  5. rename flash:config.text flash:config.OLD
  6. You should see no errors during the above, if so, type boot and press enter.

From here you can reconfigure the switch from scratch if you like, or you can get into the switch and copy the config.OLD file into running memory and then change your passwords.


Strange Juniper SRX CPU spikes – Tracking the bugger..

I had identified a potential issue with my Juniper SRX firewalls last week. When I seem to have CPU spikes, the routing engine CPU (and traffic) never really seem crazily high. PPS is pretty normal too.

I found a potential correlation with a BSD process spiking that causes the kernel CPU to spike. The high %age of g_down thread in FreeBSD indicates that higher level entities i.e., user processes, try to access physical devices like disk/storage/memory/IO with such a high rate that there is a resource crunch. This further takes the kernel processes to high values. Therefore, you will see g_down process high at the same time as the kernel level processes.

I’ve finished writing a monitor tool that will track this, hopefully the sensitivity is enough that it will one way or another support the theory of this.

I have other things we need to start monitoring, but this will hopefully help me gain more visibility into the performance of the Juniper firewalls.

It’s an APM component attached to a Linux node in Orion. It’s also graphing these two statistics, but it can be monitored for anywhere because of the unfortunate convoluted way of creating it.

I will add more monitors based upon the JunOS shell script wrapper I created as time goes by.

You may have better ideas of implementing this but this was the quickest way for me, right now.

I created a read-only account on the Juniper firewalls. This allows into JunOS, but not into the shell. Now, I could get around this and cron it straight up on the firewall; and set up SSH keys to connect to secondary nodes in the cluster and so on. However, Orion has a strange way of working with a monitor, so this is how I have implemented it for now. Unfortunately, it does not attach to the actual firewall nodes, but I have created a custom monitoring page with each component purely for the Juniper layer.

The first script is the expect script, to authenticate on the firewall.


#!/usr/bin/expect -f
set password [lrange $argv 0 0]
set ipaddr [lrange $argv 1 1]
set scriptname [lrange $argv 2 2]
set arg1 [lrange $argv 3 10]
set timeout -1
spawn ssh <username>@$ipaddr $scriptname $arg1
match_max 100000
expect “*?assword:*”
send — “$password\r”
send — “\r”
expect eof

The bootstrap shell script,

echo -e “Message.<fw_name>gdN0: <fw_name> g_down Node 0 CPU”
echo -e “Message.<fw_name>gdN1: <fw_name> g_down Node 1 CPU”
echo -e “Statistic.<fw_name>gdN0:”`/Monitoring/Juniper/srx.exp <password> <fw_cluster_ip> show system processes node 0 detail | grep g_down | awk ‘{print $3}’`
echo -e “Statistic.<fw_name>gdN1:”`/Monitoring/Juniper/srx.exp <password> <fw_cluster_ip> show system processes node 1 detail | grep g_down | awk ‘{print $3}’`

This is all added into a 60 second cronjob on the Linux monitoring host:

* * * * * /Monitoring/Juniper/ > /Monitoring/Juniper/SRX.stats

The output is:

Message.<fw_name>gdN0: <fw_name> g_down Node 0 CPU
Message.<fw_name>gdN1: <fw_name> g_down Node 1 CPU

From here I created a new Application Performance Monitor template within Orion. It basically just cats the output of that stats file. I did think about making things happen on the firewall (as mentioned above), but I decided I wanted to keep this all together on the Linux host. If I do this, I can expand the capability to new monitoring features and attach it to any Juniper node globally pretty easily – and only have one place to edit any code.

Hope this helps!



Monitoring CPU:

jnxOperatingCPU /

Path: iso . org . dod . internet . private . enterprises . juniperMIB . jnxMibs . jnxBoxAnatomy . jnxOperatingTable . jnxOperatingEntry . jnxOperatingCPU

This will allow you to track routing engine CPU stats.