Redux Blog All Posts in Platform Development

Connecting the ShrewSoft VPN client to a Juniper SRX

(April 23, 2012, Posted in Platform Development by Brian Shore)

Our standard architecture for private clouds includes security appliances that provide a fairly comprehensive set of security features from stateless firewall to full intrusion detection. We like to use Juniper SRX devices, and I admit I'm a big fan JunOS.

In the same vein as this post by Thomas, a client wished to use a Linux system to connect to their SRX-powerd IPSec VPN using the Shrew Soft client. Searching the tubes for other people's experience connecting these two end points yielded... nothing. But after some poking and prodding, I got the client to connect. The main elements of the configuration that weren't immediately obvious were:

• Use "push" configuration mode
• Manually add the policies needed for the given VPN

I find the configuration modes are always named differently from one client to another -- Shrew Soft has push, pull, and dhcp; VPN Tracker has mode config, mode config (active), and mode config (passive); &c. Standard terminology would definitely simplify cross-vendor integrations. I would have liked to have this VPN client pulling the network policies from the SRX. VPN Tracker is able to do this, and the Shrew Soft client has a configuration option for this, but it didn't work in my test setup. Below is the complete client configuration. The test node was a Debian 6 VM, extra stuff beyond the base install was added just to build the client (2.1.7, current at the time of writing).

b:auth-mutual-psk:eA==
n:client-addr-auto:1
n:client-banner-enable:1
n:client-dns-auto:1
n:client-dns-used:1
n:network-dpd-enable:1
n:network-frag-size:540
n:network-ike-port:500
n:network-mtu-size:1380
n:network-natt-port:4500
n:network-natt-rate:60
n:network-notify-enable:1
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-kbytes:0
n:phase1-life-secs:28800
n:phase2-keylen:256
n:phase2-life-kbytes:0
n:phase2-life-secs:3600
n:phase2-pfsgroup:2
n:policy-list-auto:0
n:policy-nailed:1
n:vendor-chkpt-enable:0
n:version:2
s:client-ip-addr:0.0.0.0
s:client-ip-mask:255.255.255.255
s:client-dns-addr:8.8.8.8
s:client-dns-suffix:
s:network-host:vpn.example.com
s:client-auto-mode:push
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk-xauth
s:ident-client-type:fqdn
s:ident-client-data:vpn.example.com
s:ident-server-type:address
s:phase1-exchange:aggressive
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
s:policy-level:auto
s:policy-list-include:10.10.10.0 / 255.255.255.0

-- bks

Juniper SRX and JunOS with VPN Tracker

(January 13, 2012, Posted in Platform Development by Thomas Brenneke)

I wish this article had been published prior to engaging our first series of SRX units. Over the last couple of months we’ve actively deployed close to (20) SRX 240 units, primarily in active/passive chassis clusters.

Quite a few of our customers rely on VPN connectivity to manage their private clouds. Quite a few of our clients are also Mac shops, similar to our organization.

A popular, yet expensive VPN client is made by our friends at Equinux called VPN Tracker. This is without question the most powerful and robust VPN client I’ve ever seen on any platform be it Mac, Windows or Linux.

That being said, during a transition from Watchguard to Juniper as our Security gateway provider (and Force10 to Juniper MX for Routing) a poor assumption made on our part was that the SRX series was supported out of the box by VPN Tracker. This article is being written because it was, and currently is not supported.

For anyone following the Juniper Security track, it is clear from the writers of JunOS Security by O’Reilly that the SRX is being geared to replace the Netscreen and SSG families. ScreenOS will be no more, JunOS is the future for security at Juniper.

Through a combination of many resources including but not limited to Juniper TAC, a third party site to site (not dynamic VPN) windows based IPSec client (which had documented support by JunOS) and a great deal of troubleshooting I was able to engineer a working configuration for IPSec connectivity from VPN Tracker to an SRX endpoint.

Lets start by saying the standard proposal set should not be used. This was my first glimmer into not using default sets within JunOS. This essentially predefines a set of criteria to be used for the proposal to have a conversation and engage with the endpoint. Specifically:

standard - Standard set of two set of IKE proposals: Proposal 1— Preshared key, 3DES encryption, and Diffie-Hellman Group 2 and SHA-1 authentication. Proposal 2—Preshared key, Advanced Encryption Standard (AES) 128-bit encryption, and Diffie-Hellman Group 2 and SHA-1 authentication.

Despite all efforts we could not engage in a Proposal 1 agreement within VPN Tracker, initial theory is on the Triple DES encryption. What follows is a documented and working proposal set to use for your Dynamic VPN IPSec configurations within JunOS:

set security zones security-zone Public interfaces ge-X/X/X.X host-inbound-traffic system-services ike
set security ike proposal PSK-AES128-SHA1-DH2 authentication-method pre-shared-keys
set security ike proposal PSK-AES128-SHA1-DH2 dh-group group2
set security ike proposal PSK-AES128-SHA1-DH2 authentication-algorithm sha1
set security ike proposal PSK-AES128-SHA1-DH2 encryption-algorithm aes-128-cbc
set security ike proposal PSK-AES128-SHA1-DH2 lifetime-seconds 28800
set security ike proposal PSK-AES256-SHA1-DH2 authentication-method pre-shared-keys
set security ike proposal PSK-AES256-SHA1-DH2 dh-group group2
set security ike proposal PSK-AES256-SHA1-DH2 authentication-algorithm sha1
set security ike proposal PSK-AES256-SHA1-DH2 encryption-algorithm aes-256-cbc
set security ike proposal PSK-AES256-SHA1-DH2 lifetime-seconds 28800
set security ike policy ike-dyn-vpn-policy mode aggressive
set security ike policy ike-dyn-vpn-policy proposals PSK-AES128-SHA1-DH2
set security ike policy ike-dyn-vpn-policy proposals PSK-AES256-SHA1-DH2
set security ike policy ike-dyn-vpn-policy pre-shared-key ascii-text "XXXX"
set security ike gateway dyn-vpn-local-gw ike-policy ike-dyn-vpn-policy
set security ike gateway dyn-vpn-local-gw dynamic hostname reduxftw
set security ike gateway dyn-vpn-local-gw dynamic connections-limit 10
set security ike gateway dyn-vpn-local-gw dynamic ike-user-type shared-ike-id
set security ike gateway dyn-vpn-local-gw external-interface ge-X/X/X.X
set security ike gateway dyn-vpn-local-gw xauth access-profile dyn-vpn-access-profile
set security ipsec proposal ESP-AES128-SHA protocol esp
set security ipsec proposal ESP-AES128-SHA authentication-algorithm hmac-sha1-96
set security ipsec proposal ESP-AES128-SHA encryption-algorithm aes-128-cbc
set security ipsec proposal ESP-AES128-SHA lifetime-seconds 28800
set security ipsec proposal ESP-AES256-SHA protocol esp
set security ipsec proposal ESP-AES256-SHA authentication-algorithm hmac-sha1-96
set security ipsec proposal ESP-AES256-SHA encryption-algorithm aes-256-cbc
set security ipsec proposal ESP-AES256-SHA lifetime-seconds 28800
set security ipsec policy ipsec-dyn-vpn-policy perfect-forward-secrecy keys group2
set security ipsec policy ipsec-dyn-vpn-policy proposals ESP-AES128-SHA
set security ipsec policy ipsec-dyn-vpn-policy proposals ESP-AES256-SHA
set security ipsec vpn dyn-vpn ike gateway dyn-vpn-local-gw
set security ipsec vpn dyn-vpn ike ipsec-policy ipsec-dyn-vpn-policy

Pretty basic configuration, fill in the X’s where needed and you’ve got viable usage of AES128 or 256.

On the VPN Tracker side simply create a custom profile and fill in your phase 1 and phase 2 settings as appropriate.

Also, don’t forget to insert your Public_Bound source bound natting in front of your last resort source-address with source-nat off.

Lastly, remember that security policies in JunOS flow downward. Ensure your security policy to handle this traffic is in front of any-permit.

Hopefully this helps the next engineer working with similar platforms.

Any questions, I'm thomas@networkredux.com. Cheers.

Technologies behind our Dashboard and Website

(June 15, 2011, Posted in Platform Development )

I've had quite a few requests to go into detail about the technologies we use to power our website and our automated dashboard, so today I'd like to go into detail about that.

Website

Our website is a custom CMS that I built on top of the Sinatra framework. I chose Sinatra for a couple reason: 1) I am a ruby developer, so it's very easy for me to build it exactly how i want it to work, and 2) it's an incredibly lightweight and easy to manage framework.

Most of the pages are static erb templates, while our blog and answers are stored in MongoDB. If you're not familiar with mongo, I highly recommend you look into it; it's a very fast and scalable document-based database.

Composing our blog posts and answers is done using markdown with the redcarpet ruby gem.

Searching on both the blog and answers section is handled by taking all of words in the body & title of the post and create an array of keywords.

Example:

title = title.gsub(/<\/?[^>]*>/, "").gsub(/\W+/, ' ').downcase
content = content.gsub(/<\/?[^>]*>/, "").gsub(/W+/, ' ').downcase
keywords = (title + ' ' + content).split.uniq

This may seem a little 'messy', but it actually works quite nicely. I do some other logic behind the scenes to take out words like 'the' and 'a' to cut out some fat.

Dashboard

Our dashboard is made up of a collection of technologies and languages. The main application is a Rails 3 app running on nginx and Passenger.

When designing the main architecture, we chose to build the app to leverage queuing as much as possible so the user experience would always be fast.

Queue

For queuing, were using Resque which uses the Redis database, and this is monitored with god. To learn more about this, here is a great blog post that the Resque developers put out: https://github.com/blog/542-introducing-resque.

From within the application, all orders, device changes (resize, restart, shutdown, etc), reverse dns, and email are queued up. This is mainly why our dashboard is so quick. It also allows us to handle errors very gracefully, if a worker fails to complete it's job for whatever reason, we can deal with that transparently behind the scenes; the customer doesn't need to be involved in that process.

Provisioning

Provisioning of the VM is handled by a perl driver I wrote to speak with our virtualization platform. Even though I'm by no means a perl developer, I chose perl for it's speed and socket connections. The perl driver spits out the raw data for the ruby-based worker to process the response. In internal testing, we found that this method was substantially faster over letting ruby make the socket requests.

Device Metrics

All of our device metrics are done by a separate set of workers polling all of the devices every few minutes, and then storing that data into MongoDB.

Were using the Highcharts graphing engine to generate our graphs.

If you have any questions, please feel free to contact me at kris at networkredux.com