General

Load-Balancing Transparent Redirect with JunOS

Load-Balancing Transparent Redirect with JunOS

Since setting up ‘Transparent Redirect with JunOS‘ some time ago I’ve been pleased with the way things have worked out. With a Blue Coat ProxySG appliance attached to my SRX210, intercepting is highly effective and when mixed with the excellent filtering capabilities of the ProxySG and Blue Coat’s ‘Web Pulse’ online rating system and their Web Filter database you get a very good level of protection from malware and malicious content.

Having gone through the Juniper Security course a while back, I’d spoken to the course instructor at the time about implementing load-balancing across multiple filtering devices to add capacity to the solution and perhaps enhance the speed with which content is retrieved. The course instructor had kindly given me a few tips on how to implement it, and so with some time to spare, I decided to try the setup.

As I only have one ProxySG to use, I decided to setup two Squid-Cache VM’s to test how to implement the solution. Admittedly, Squid-Cache doesn’t have the same level of filtering capabilities as the ProxySG, so instead, I mixed the load-balancing implementation with Blue Coat’s ThreatPulse cloud service. As a Blue Coat Blue Knight, I’m fortunate to have access to the TP Cloud service offered by Blue Coat, and one of the methods for accessing the service is using Proxy Forwarding (e.g it would work with ISA, Squid, ProxySG, etc or any other proxy solution which can forward to upstream servers). I won’t go into the ThreatPulse service setup here, however (maybe another time).

The topology is as follows –

LB-SRX2

All devices are in the Trust zone for my purposes, but there’s nothing to stop you putting them in separate zones if you wish.

First off, as with the single transparent intercept solution I’ve written about before, we setup a routing instance to deal with what to do with the traffic once the firewall filter has intercepted it.

Here’s my Squid ‘routing-instance’ setup –

SQUID-ROUTE-INSTANCE

Both static route destinations have a ‘qualified-next-hop’ with preference of 5.

Here that is in display set form.

set routing-instances SQUID instance-type forwarding
set routing-instances SQUID routing-options options syslog level info
set routing-instances SQUID routing-options options syslog level debug
set routing-instances SQUID routing-options static route 0.0.0.0/0 qualified-next-hop 10.24.1.3 preference 5
set routing-instances SQUID routing-options static route 0.0.0.0/0 qualified-next-hop 10.24.1.4 preference 5
set routing-instances SQUID forwarding-options load-balance per-prefix hash-seed 1

The key here, to make load-balancing work, it seems is to set the forwarding-options addition to the routing-instance. The per-prefix hash-seed value is what makes the Packet Forwarding Engine perform the load-balancing.

Next, the filter, which is similar to the previous filter setup for redirecting to a single host (it’s the routing-instance configuration which makes the difference).

SQUID-FIREWALL-FILTER

Here that is in display set format –

set firewall family inet filter proxysg-fbf term t1 from source-address 172.16.129.10/32
set firewall family inet filter proxysg-fbf term t1 from source-address 172.16.129.29/32
set firewall family inet filter proxysg-fbf term t1 from destination-address 0.0.0.0/0
set firewall family inet filter proxysg-fbf term t1 from destination-port http
set firewall family inet filter proxysg-fbf term t1 then count redirected-squid
set firewall family inet filter proxysg-fbf term t1 then routing-instance SQUID

You’ll notice my filter is called ‘proxysg-fbf’, this is because I’ve added the new filter term to redirect to the SQUID routing-instance into my existing filter-based forwarding configuration. I simply want to redirect two particular hosts to the SQUID instance for testing purposes, everything else would still go to the PROXYSG routing-instance. As with my previous example article, I’ve added a ‘count’ to the filter term to show me that traffic is matching.

For completeness, here’s the partially full filter including the use of both routing-instances (I’ve left out a filter term which has over 14,000 entries in it related to my article on ‘Dynamic Blocklists with Junos‘) –

set firewall family inet filter proxysg-fbf term t1 from source-address 172.16.129.10/32
set firewall family inet filter proxysg-fbf term t1 from source-address 172.16.129.29/32
set firewall family inet filter proxysg-fbf term t1 from destination-address 0.0.0.0/0
set firewall family inet filter proxysg-fbf term t1 from destination-port http
set firewall family inet filter proxysg-fbf term t1 then count redirected-squid
set firewall family inet filter proxysg-fbf term t1 then routing-instance SQUID
set firewall family inet filter proxysg-fbf term t2 from source-address 10.21.1.0/24
set firewall family inet filter proxysg-fbf term t2 from destination-address 10.11.3.0/24
set firewall family inet filter proxysg-fbf term t2 then accept
set firewall family inet filter proxysg-fbf term t3 from source-address 10.21.1.0/24
set firewall family inet filter proxysg-fbf term t3 from source-address 172.16.129.0/24
set firewall family inet filter proxysg-fbf term t3 from destination-address 0.0.0.0/0
set firewall family inet filter proxysg-fbf term t3 from destination-port http
set firewall family inet filter proxysg-fbf term t3 then count redirected-proxysg
set firewall family inet filter proxysg-fbf term t3 then routing-instance PROXYSG
set firewall family inet filter proxysg-fbf term default then accept

Term t1 – redirects to the Squid routing-instance

Term t2 – sets a bypass to term t3 if the source is 10.21.1.0/24 and the destination is 10.11.3.0/24

Term t3 – redirects to the ProxySG routing-instance.

Term default – accepts everything else. We need this, otherwise all other traffic would be dropped.

The firewall filter is assigned to an interface in the same way as before –

SQUID-FBF

Here, I’m assigning the filter to an ingress/egress vlan on my SRX, but you could just as easily assign it to the ingress interface of VLAN 11 per my topology above.

My Squid configuration is very straight-forward. Both Virtual Machines have the following –

http_port 3128 intercept
acl localnet src 10.21.1.0/24 172.16.129.0/24
http_access allow localnet
forwarded_for on
cache_peer proxy.threatpulse.com parent 8080 0 no-query default
never_direct allow all

With Squid, as I’m intercepting transparently, I also needed to set the following in IPTables –

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

In the Squid Access logs, we can observe the traffic matching the filter –

PROXY2 PROXY1

Notice that both Squid-Cache processes are forwarding to proxy.threatpulse.com as per the cache_peer directive.

You can also observe traffic matching the filter on the SRX itself. Note the ‘redirected-squid’ counter.

SQUID-FBF

So, after all this is done, how do I know I’m talking to a proxy, not the destination website from the clients perspective?

Well, one way is to do a ‘whats my ip’ type lookup. For example –

SQUID-WHATSMYIP

As you can see, we can detect whether a proxy is involved by using a lookup against request header values, like X-Forwarded-For. The IP also isn’t my home IP which I’d expect if I weren’t being sent to ThreatPulse.

I can also confirm I’m being filtered by ThreatPulse by attempting to visit a site which is blocked per my configured policy –

SQUID-PLAYBOY

So there it is. Load-balanced Transparent Redirection using JunOS, Squid, and the extra benefit of Blue Coat’s ThreatPulse Cloud service.

Allot NetEnforcer Cacti Graphs

Allot NetEnforcer Cacti Graphs

I’ve been using an internally written Cacti host template to graph CPU, Memory and Storage statistics for the excellent Allot NetEnforcer (AOS platform) on our AC1400 appliance for a while now, and as they’ve seemed to be OK, I’m posting them here for anyone who’s interested.

AOS-CACTI

The interface statistics are taking off of the built-in IF-MIB table which the NE will respond on. The CPU/Memory/Storage are from the ALLOT-MIB.

ALLOT-MIB::alSensorType.0.2001 = INTEGER: fan(2)
ALLOT-MIB::alSensorType.0.2002 = INTEGER: fan(2)
ALLOT-MIB::alSensorType.0.2003 = INTEGER: fan(2)
ALLOT-MIB::alSensorType.0.2004 = INTEGER: fan(2)
ALLOT-MIB::alSensorType.0.3001 = INTEGER: powerSupply(3)
ALLOT-MIB::alSensorType.0.3002 = INTEGER: powerSupply(3)
ALLOT-MIB::alSensorType.0.10001 = INTEGER: cer(10)
ALLOT-MIB::alSensorType.0.11001 = INTEGER: noc(11)
ALLOT-MIB::alSensorType.0.12001 = INTEGER: activeLines(12)
ALLOT-MIB::alSensorType.0.13001 = INTEGER: activePipes(13)
ALLOT-MIB::alSensorType.0.14001 = INTEGER: activeVcs(14)
ALLOT-MIB::alSensorType.0.15001 = INTEGER: registerSubscr(15)
ALLOT-MIB::alSensorType.1.1001 = INTEGER: temperature(1)
ALLOT-MIB::alSensorType.1.1002 = INTEGER: temperature(1)
ALLOT-MIB::alSensorType.1.4001 = INTEGER: cpu(4)
ALLOT-MIB::alSensorType.1.5001 = INTEGER: memory(5)
ALLOT-MIB::alSensorType.1.6001 = INTEGER: storage(6)
ALLOT-MIB::alSensorType.1.10001 = INTEGER: cer(10)
ALLOT-MIB::alSensorType.1.11001 = INTEGER: noc(11)
ALLOT-MIB::alSensorType.1.12001 = INTEGER: activeLines(12)
ALLOT-MIB::alSensorType.1.13001 = INTEGER: activePipes(13)
ALLOT-MIB::alSensorType.1.14001 = INTEGER: activeVcs(14)
ALLOT-MIB::alSensorRawValue.0.2001 = INTEGER: 2
ALLOT-MIB::alSensorRawValue.0.2002 = INTEGER: 2
ALLOT-MIB::alSensorRawValue.0.2003 = INTEGER: 2
ALLOT-MIB::alSensorRawValue.0.2004 = INTEGER: 2
ALLOT-MIB::alSensorRawValue.0.3001 = INTEGER: 0
ALLOT-MIB::alSensorRawValue.0.3002 = INTEGER: 7
ALLOT-MIB::alSensorRawValue.0.10001 = INTEGER: 7
ALLOT-MIB::alSensorRawValue.0.11001 = INTEGER: 344
ALLOT-MIB::alSensorRawValue.0.12001 = INTEGER: 1
ALLOT-MIB::alSensorRawValue.0.13001 = INTEGER: 8
ALLOT-MIB::alSensorRawValue.0.14001 = INTEGER: 12
ALLOT-MIB::alSensorRawValue.0.15001 = INTEGER: 0
ALLOT-MIB::alSensorRawValue.1.1001 = INTEGER: 24
ALLOT-MIB::alSensorRawValue.1.1002 = INTEGER: 31
ALLOT-MIB::alSensorRawValue.1.4001 = INTEGER: 5
ALLOT-MIB::alSensorRawValue.1.5001 = INTEGER: 61
ALLOT-MIB::alSensorRawValue.1.6001 = INTEGER: 71
ALLOT-MIB::alSensorRawValue.1.10001 = INTEGER: 7
ALLOT-MIB::alSensorRawValue.1.11001 = INTEGER: 344
ALLOT-MIB::alSensorRawValue.1.12001 = INTEGER: 1
ALLOT-MIB::alSensorRawValue.1.13001 = INTEGER: 8
ALLOT-MIB::alSensorRawValue.1.14001 = INTEGER: 12

The template can be downloaded from here

 

Freeview Multicast Streaming

Freeview Multicast Streaming

I’ve spent some of this weekend setting up multicast streaming on my home network. The reason I’ve done this is because whilst our current bedroom has an aerial socket in it, we’re about to move to a bedroom which doesn’t. Whilst I could have run another cable from the attic to the new room (which has already been decorated), I thought it would be much more fun to try to enable a new network service – Multicast Streaming.

There are plenty of options for multicast streaming, VLC, dvblast, set-top-boxes, etc, I settled on using MUMUDVB. A very useful article has been written about doing just about what I wanted (but using dvblast) by TheAngryTechnican which has proven very useful for getting things up and running (kudos to him). I chose to use VLC as my client, mainly as I’m unaware of any other client which works so well with this setup.

For my setup, I’ve used an old Atom Mini-ITX box I had laying around. It’s quite old now, but still has its uses, and for streaming multicast, it’s actually proven to be overkill. The hardware is as follows –

  • 1 x Atom ARK 330 1.6Ghz Quad-Core CPU
  • 1 x 250GB Hitachi 2.5″ SATA HD
  • 1 x 1GB Memory
  • 2 x WinTV Nova-T USB DVB-T Receivers
  • 1 x WinTV Nova-T 500 PCI Dual DVB-T Receiver

The Atom has a built-in Realtek 8168 Gigabit Ethernet card on it so for the purposes of multicast, this is more than adequate. There’s only one PCI slot available on the device, hence why I used USB receivers to fulfil my requirements for the transponder frequencies I needed.

I’d chosen to use Debian as my OS of choice for two reasons; It’s the Linux OS I’m used to using, and it has the mumudvb package included as part of it’s apt-sources. To install, simply run –

apt-get install mumudvb

For the WinTV Nova-T USB and PCI receivers, I had to download the firmware necessary for this card from LinuxTV and place it in my /lib/firmware directory in order to get the cards loaded correctly by the Debian OS when it booted –

DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
DiB0070: successfully identified
DVB: registering adapter 1 frontend 0 (DiBcom 7000PC)...
DiB0070: successfully identified
DVB: registering adapter 2 frontend 0 (DiBcom 3000MC/P)...
MT2060: successfully identified (IF1 = 1246)
DVB: registering adapter 3 frontend 0 (DiBcom 3000MC/P)...
MT2060: successfully identified (IF1 = 1237)

Once the firmware was loaded following a reboot, we need to configure mumudvb.

The frequency information is available all over the place on the Interweb, some of it confusing, however here are the ones you need if you want all Freeview channels from the Mendip Transmitter.

690
698
722
738
754

You’ll note there’s five frequencies there, which means I don’t have enough DVB-T cards in my setup (each card card only lock on to one frequency at a time). Thats fine, I’ve left out 722 for now. I might get another USB DVB-T in the future, but the only channel I’m interested in on that frequency is Yesterday and I can live without that for now.

As there are several transponder frequencies needed to get the Freeview channels I need, I created four configuration files, each almost identical, except for the frequency and a couple of other items.

Mumudvb comes with the option to auto configure everything for you (autoconfiguration=full). I used that option in my configuration files, however I needed to specify some additional options to get things working with all four DVB-T cards at the same time.

All four configuration files had the following identical settings –

timeout_no_diff=100
dvr_thread
rewrite_pat=1
rtp_header=1
check_status=1
pol=h
srate=27500
autoconfiguration=full
autoconf_radios=1
autoconf_pid_update=0
autoconf_ip4_header=239.10
multicast_ttl=2
multicast_auto_join=1
unicast=1
ip_http=172.16.129.253
sap=1
sap_default_group=MCAST

The only differences added in each file were as follows –

Transponder frequency 690

card=3
freq=690
port_http=80

Transponder frequency 698

card=0
freq=698
port_http=81

Transponder frequency 738

card=2
freq=738
port_http=82

Transponder frequency 754

card=1
freq=754
port_http=83

The ‘port_http’ parameter in each of the individual frequencies above specifies a web service with provides a ‘playlist.m3u’ file which you can use for clients that aren’t able to receive multicast SAP announcements. In the identical section, you define the IP address hosting those web services using the ‘ip_http’ parameter. You can download each of these files, and open them within VLC as Playlists then save a ‘master’ playlist for use later. Clients accessing these Playlists do so using Unicast.

After all of the above is done, you should end up with four (in my case at least) configuration files, one for each frequency. Here’s an example of one of my files (for frequency 690) –

card=3
freq=690
timeout_no_diff=100
dvr_thread
rewrite_pat=1
rtp_header=1
check_status=1
pol=h
srate=27500
autoconfiguration=full
autoconf_radios=1
autoconf_pid_update=0
autoconf_ip4_header=239.10
multicast_ttl=2
multicast_auto_join=1
unicast=1
ip_http=172.16.129.253
port_http=82
sap=1
sap_default_group=MCAST

With the configuration files written, I started four separate mumudvb processes, calling each configuration file with each process with a simple script created in /usr/bin (I ran ‘chmod +x /usr/bin/mumustart.sh‘ to make it executable).

#!/bin/sh
mkdir /var/run/mumudvb
/usr/bin/mumudvb -c /etc/mumuf690.conf &
/usr/bin/mumudvb -c /etc/mumuf698.conf &
/usr/bin/mumudvb -c /etc/mumuf754.conf &
/usr/bin/mumudvb -c /etc/mumuf738.conf &
exit 0

Mumudvb comes with it’s own init script under Debian, but I was never able to figure out why I got the following error when I started it. I might report back if I ever find out.

ERRO:  DVB:  FRONTEND DEVICE: /dev/dvb/adapter1/frontend0 : Permission denied

Also, on reboot, the /var/run/mumudvb directory seemed to be deleted so I got the following error too.

WARN:  Logs:  saving_filename /var/run/mumudvb/mumudvb_generated_conf_card0_tuner0: Permission denied

So, the ‘mumustart.sh’ script, created in /usr/bin got around those errors. The script is invoked at startup in /etc/rc.local, as follows –

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
/usr/bin/mumustart.sh
exit 0

With all four processes running, mumudvb isn’t that demanding in relation to CPU, and barely at all in relation to memory.

DVB-CPU

The difference between standalone dvblast and mumudvb is that mumudvb handles the creation of the SAP streams for you. Like so –

Channel number : 0, name : "BBC ONE" service id 4161 
#011Multicast4 ip : 239.10.0.0:1234
#011Unicast : Channel accessible via the master connection, 172.16.129.253:80
Channel number : 1, name : "BBC TWO" service id 4287 
#011Multicast4 ip : 239.10.0.1:1234
#011Unicast : Channel accessible via the master connection, 172.16.129.253:80
Channel number : 2, name : "BBC THREE" service id 4288 
#011Multicast4 ip : 239.10.0.2:1234
#011Unicast : Channel accessible via the master connection, 172.16.129.253:80
Channel number : 3, name : "BBC NEWS" service id 4352 
#011Multicast4 ip : 239.10.0.3:1234
#011Unicast : Channel accessible via the master connection, 172.16.129.253:80
Channel number : 4, name : "BBC Red Button" service id 4416 
#011Multicast4 ip : 239.10.0.4:1234
#011Unicast : Channel accessible via the master connection, 172.16.129.253:80
Channel number : 5, name : "BBC FOUR" service id 4544 
#011Multicast4 ip : 239.10.0.5:1234
#011Unicast : Channel accessible via the master connection, 172.16.129.253:80
Channel number : 6, name : "CBBC Channel" service id 4608 
#011Multicast4 ip : 239.10.0.6:1234

So now you have things running, you can fire up VLC and navigate to the Local Network / SAP Streams section.

SAP-STREAMS

Choose a channel from the SAP listing, and ‘Voila’!

STREAM-DONE

 

For those clients which can’t use SAP announced channels, you can use plain old unicast streaming using the links which are created by mumudvb with the port_http and ip_http options in the configuration files.

For this, you simply download the M3U playlist from each server process port, and add it to VLC. For example –

http://172.16.129.253/playlist.m3u
http://172.16.129.253:81/playlist.m3u
http://172.16.129.253:82/playlist.m3u
http://172.16.129.253:83/playlist.m3u

Once you’ve downloaded the files, add them to VLC, then save a local M3U master playlist which you can open later. Like so –

PLAYLISTS-M3U

If you wanted to be selective about the channels you announce via SAP, I urge you to look at The AngryTechnican blog where you can do the above using dvblast, and minisapserver.

One of the things I’ve noticed is that some of the channels available over Unicast don’t seem to have been announced by the SAP server. BBC R5SX, for example, doesn’t appear in the SAP list. When I figure out why this might be, I’ll report back.

DISCLAIMER

To do any of the above if you live in the UK, you MUST have a TV License

Juniper SSL-VPN & Blue Coat’s ProxyClient

Juniper SSL-VPN & Blue Coat’s ProxyClient

I posted this (via some contacts at Blue Coat) in it’s original form to the Blue Knights wiki. I thought the general population of Blue Coat users would find it useful too.

Requirement

The requirement was to provide automatically directed explicit internet access with no local break-out for Juniper SA clients. When users were disconnected from the corporate network, the requirement was to have BCWF categories blocked by default thus maintaining protection and control of access even when away from the network.

The most useful of those categories when users aren’t connected to the network are the Web Pulse categories – Spyware/Malware, Spyware/Malware Sources, Phishing and Suspicious. These categories and the Web Pulse dynamic ratings service are worth their salt and a good reason to install the client on corporate mobile devices.

In order to provide directed ‘explicit’ proxy access to the customers network when Juniper SA clients dial in, a PAC file can be distributed from the SA with the following type of configuration.

The customers environment already had two ProxySG’s, these were explicit proxies for the internal network. We added the ADN Client Concentrator functionality.

An SA2500 acted as the ‘dial in’ service for clients. A VIP (Virtual IP Address) was assigned to the ADN/Client Manager. The VIP is required because as we discovered, using the appliance’s normal explicit IP traffic wasn’t accelerated. The reason for this is that the ADN traffic needs to traverse the ADN tunnel and arrive at a device on the other side in order for the ProxySG/Client to accelerate. The VIP provides that function without the customer having to purchase a separate unit for Client Concentrator and Explicit proxy purposes.

With this information, we configure the PAC file on a host behind the SA2500. In it, we define that 127.0.0.0/8 should not be redirected, but all other traffic IS directed to ‘PROXY <proxy>:8080’.

function FindProxyForURL(url, host)

{
    if(isInNet(host, "127.0.0.0", "255.0.0.0"))
    {
        return "DIRECT";
    } else {
        return "PROXY <proxy>:8080; DIRECT";
    }
}

We bypass 127.0.0.0/8 because this would otherwise block the ProxyClient from functioning. Further tightening up could occur to avoid ‘Proxy Avoidance’ software from bypassing filtering.

Once this is done, we can configure our Network Connect connection profile.

First with no split-tunneling.

PC-VIP-SANCST

Then with the PAC file location.

PC-VIP-SANC-PACLOC

For the test, I setup a new role mapping so that my proxy settings matched the PAC requirements.

PC-VIP-SANC-ROLEMAP

With this done, we can open up the Network Connect client and connect to the network.

Third-party applications are blocked because no automated internet settings were provided.

PC-VIP-Timeout

Whereas IE is able to browse because it’s been configured to use the PAC file.

PC-VIP-Success

Using the VIP as our explicit proxy allows the Proxy Client to intercept and accelerate content which ordinarily can’t be cached. For example, if you were to watch your favourite You Tube video, clear the cache and reboot then connect to the SA again to watch the same video, the video should be byte-cached as in the example below.

Client side

ADN-PC-YouTube

ADN-PC-YouTube-1

ProxySG ADN Concentrator side

ADN-ProxyClient-Tunnel-Cached

So, with the capabilities of the ProxyClient from an acceleration perspective proven, how about that requirement for control of users internet access based on categories, even when they aren’t connected to the network? Well, this is handled from the CM (Client Manager) console. Here you can define the BCWF categories (along with Local Database one’s if you use a Local DB or even other 3rd-party databases like the Internet Watch Foundation) so that they are allowed or blocked. Safe-Search can be enforced here also, along with filtering of HTTPS connections.

PC-BCWF-1

The effect is, when a user isn’t connected to your corporate network, and they attempt to view a site falling within a blocked category they’re denied access.

PC-BCWF-2

The Block Page can be customised to make the URL more in-tune with your corporate identity.

The ProxyClient uses the same Web Pulse cloud service as Blue Coat’s K9 Web Protection client. URL requests are submitted to Web Pulse to validate the category. Unclassified URL’s are scanned and rated on-the-fly, returning a categorisation to the client in order to make a filtering decision.

This method for corporate access provides the following benefits.

  • Centralised policy control
  • Reporting per-user if you have Blue Coat Reporter in use.
  • Protection from malicious content via centrally published and controlled BCWF categories such as Phishing, Suspicious, Spyware\Malware Sources, and Spyware Effects when both inside AND outside the corporate extranet.
  • Caching of non-cacheable content in Byte-Cache for remote workers. This includes YouTube (as above) and other streaming service such as BBC iPlayer. Under normal circumstances, this traffic cannot be cached (Pragma: no-cache is returned) or can only be cached for a short period. Using the ProxySG’s Byte-Cache we can store this content.

The same deployment type could be used when installing appliances. If the customer requires a centrally managed explicit proxy but wants ADN acceleration also (on the same box) for remote users we can use the ProxySG Manager/Concentrator with a VIP configured so traffic can ‘exit’ the tunnel at the core and be accelerated. Non-cacheable content would be stored in byte-cache.

The ProxyClient provides some great functionality in the form of WAN Optimisation but when it’s coupled with the Web Pulse cloud service for dynamic rating of URL’s it adds amazing protection to a roaming corporate device that no other WAN Optimisation vendors client can. And best of all, it’s free! The only requirement being that you have a Blue Coat appliance and a Web filter license option.

CACTI Graphs for Blue Coat ProxySG

SGOS 5.x has some great added SNMP sub-tree bits which seems to correlate with MMC/Sky console information (but with added server connection information).

I’ve added some of our lab equipment to our resident Cacti server and so far the results are quite favorable.

Heres the information I used.

:: BLUECOAT-SG-PROXY-MIB ::

.1.3.6.1.4.1.3417.2.11.3.1.3 in English is the sgProxyHttpConnections table of BLUECOAT-SG-PROXY-MIB which gives:

sgProxyHttpClientConnections
sgProxyHttpClientConnectionsActive
sgProxyHttpClientConnectionsIdle
sgProxyHttpServerConnections
sgProxyHttpServerConnectionsActive
sgProxyHttpServerConnectionsIdle

Reading the subtree with command…

snmpwalk -v 2c -c <community> -m /usr/share/snmp/mibs/BLUECOAT-SG-PROXY-MIB.txt <ip> .1.3.6.1.4.1.3417.2.11.3.1.3

The following is returned…

BLUECOAT-SG-PROXY-MIB::sgProxyHttpClientConnections.0 = Gauge32: 31
BLUECOAT-SG-PROXY-MIB::sgProxyHttpClientConnectionsActive.0 = Gauge32: 1
BLUECOAT-SG-PROXY-MIB::sgProxyHttpClientConnectionsIdle.0 = Gauge32: 30
BLUECOAT-SG-PROXY-MIB::sgProxyHttpServerConnections.0 = Gauge32: 0
BLUECOAT-SG-PROXY-MIB::sgProxyHttpServerConnectionsActive.0 = Gauge32: 0
BLUECOAT-SG-PROXY-MIB::sgProxyHttpServerConnectionsIdle.0 = Gauge32: 0

This is most useful as it will give good graphs to show the average load by client and server workers,

Here’s some output from Cacti which includes the addition of CPU idle/busy graphing also (OID .1.3.6.1.4.1.3417.2.11.2.1.7 sgProxyCpuBusyPerCent and .1.3.6.1.4.1.3417.2.11.2.1.8 sgProxyCpuIdlePerCent).

SGOS54-Cacti

The Client and Server worker graphs deserve a closer look.

SGOSClientWorkers

SGOSServerWorkers

Here’s the exported cacti_host_template_proxysg.xml. When you import this template, check the ‘Use Custom RRD settings’ within Cacti.