VPN

You are currently browsing articles tagged VPN.

My Current Mac Applications

Friday, March 27, 2009 in Macintosh by slowe | 8 comments

A colleague recently bought a MacBook Pro. As a switcher, I figured he would need some recommendations on applications to use on his new Mac, and I know it had been quite some time (3 years!) since I’d discussed what Mac applications I use on a day-to-day basis. To kill two birds with one stone, I figured I would post a quick list about some of my recommended Macintosh applications.

Free or Open Source Applications

We’ll start with free and/or open source applications. (I break out “free” and “open source” because there are applications that may be available at no charge, but whose source is not available.)

Adium: This multi-service IM client is, in my opinion, the best Mac OS X IM client available, hands down. Aside from not supporting video chat—the only reason I can come up with to use iChat instead of Adium—this client does pretty much everything you need. Adium supports AppleScript and Growl notifications. Support for OTR (Off The Record) chat encryption is built in. Adium is available for download from the Adium web site.

Camino: Camino is a Mac OS X-native web browser from Mozilla. Unlike Firefox, Camino was built from the ground up to be a Mac application. It uses the same rendering engine as Firefox, but doesn’t support Firefox extensions. If you’re big on Firefox extensions, stick with the Mac build of Firefox. Visit the Camino web site for more information. If I had one complaint about Camino, it would be the fairly limited AppleScript support in the current release.

Colloquy: Into IRC? This is an excellent IRC application for Mac OS X. It supports AppleScript, Growl notifications, and can connect to multiple servers. I especially like Colloquy’s Smart Transcripts feature, which let me filter out conversations in busy chat rooms so that I can see the ones I’m most interested in joining. That’s pretty handy at times. Colloquy’s web site has more information.

Cyberduck: Cyberduck is an FTP/SFTP application. It supports AppleScript and Spotlight, Growl notifications, and Bonjour. It’s not the fastest FTP/SFTP application out there (last time I checked, that honor went to Interarchy), but it’s pretty slick. Visit the Cyberduck web site for downloads.

Growl: Growl isn’t an application per se; it’s a way for applications to supply notifications to the user in a consistent yet highly customizable fashion. Growl support is quickly becoming a “must have” for Mac applications, and you’ll see that almost all the applications I use support Growl. Surf on over to the Growl web site to download the latest version.

NetNewsWire: I’m into RSS feeds, and my RSS reader of choice is NetNewsWire. NetNewsWire offers integration with various del.icio.us clients (like Pukka) , weblog editors (like ecto), and supports AppleScript and Growl notifications. You can get NetNewsWire from the Newsgator web site. NetNewsWire is free, but not open source (at least, not to my knowledge).

Quicksilver: How does one describe Quicksilver? To call it an application launcher doesn’t really do it justice. Yes, you can use it to quickly launch applications, but you can also use it to build ad-hoc workflows like finding a contact in Address Book and creating a new e-mail message to that contact. Or finding a document and attaching it to a new e-mail message. Or quickly opening a URL in your default web browser. Or initiating a Google search. Or…well, you get the idea. I believe you can still get Quicksilver from the Blacktree web site, as well as from a Google Code site. (Some people have reported problems getting Quicksilver to run, but it’s been rock solid for me.)

Paid Applications

There are a number of paid applications that I use on a daily basis as well.

ecto: This weblog editor allows me to compose all my blog entries offline and then post them later. It works with a number of different weblog systems. I’ve been using ecto since the very first days of this site and I can’t imagine doing it any other way. More information on ecto is available from their web site.

Microsoft Office 2008: Like it or not, compatibility with the rest of the professional world still remains a critical issue, so I use Microsoft Office 2008. Yes, I know that OpenOffice exists (and has a native Aqua port), and I know that iWork supports Office formats, but it’s easier for me to just use Office and not have to worry about it. At least in this version Microsoft has added Automator support for building workflows using Office applications.

OmniFocus: If you are a GTD fan, you’ll like OmniFocus. (You may also like OmniFocus for iPhone as well, which has the ability to synchronize with the Mac version.) Projects, contexts, next actions—it’s all there. And it supports AppleScript, comes with a plug-in of sorts for Apple Mail, and leverages Growl notifications. See the OmniGroup web site for information.

OmniGraffle Professional: Also by the same folks that make OmniFocus (as if you couldn’t tell by the name of the application) comes OmniGraffle. It’s the closest you’ll come to Visio on the Mac, and in fact has the ability to read Visio binary (.VSD) files. It can also export Visio XML (.VDX) files. The OmniGroup web site has more details.

TextMate: There are numerous free text editors out there, but something out TextMate makes me like it. UNIX die-hards like it, Mac fans like it, and it offers great integration with other applications (like your FTP/SFTP client, so that you can edit files directly on remote servers). Visit the Macromates web site for information on TextMate.

Well, that’s not all the applications I use, but these are the ones that I find myself using on a daily basis. I can’t think of a day that goes by that I’m not running Adium, Camino, NetNewsWire, OmniFocus, TextMate, and Office—typically all at the same time.

Some other applications that I also use include:

So there it is—my list of most commonly-used Macintosh applications. I hope it’s helpful to some of you switchers out there!

Tags: , , , , , ,

My Ubuntu-Mac Article is Popular, I Guess

Thursday, January 8, 2009 in Linux, Macintosh by slowe | No comments

Apparently my Ubuntu-Mac integration article is quite popular; it’s been picked up for re-publication on a couple of different sites:

http://linux.sys-con.com/node/803618
http://opensource.sys-con.com/node/803618

Cool! I hope the article is useful to others.

As a quick follow-up to that article, you may recall that I ran into a strange issue with OpenVPN and mt-daapd prior to the home network rebuild. I just finished installing OpenVPN last night and, anticipating the problem, did some digging to see how I’d fix the problem this time around. Turns out there’s nothing to worry about; Avahi skips point-to-point interfaces by default, and OpenVPN tags its interfaces as point-to-point. So, everything works as expected.

Tags: , , , ,

GRE Tunnels on a Cisco Router

Friday, January 27, 2006 in Gestalt, Networking by slowe | No comments

One of my projects involved the configuration of GRE (Generic Routing Encapsulation) tunnels, encrypted by IPSec, between two locations. I was having some problems getting the tunnels to work properly, but now I’ve managed to resolve that problem, and the configuration is working well. Here’s some additional information on the problem and how it was finally corrected.

This was my first project using GRE tunnels. I’d used IPSec tunnels many times, and on many different platforms, but this time around we needed an interface that could be tracked for HSRP (Hot Standby Router Protocol) purposes, and until recently Cisco didn’t offer IPSec tunnel interfaces. (I just came across some documentation last night that indicated very recent releases of IOS offer this functionality.) So, the idea was to use GRE tunnels, track the GRE tunnels using HSRP for failover with another router, and encrypt the traffic using IPSec in transport mode.

The GRE tunnel configuration (scrubbed for sensitive data) looked something like this originally:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1
 crypto map tunnel-ipsec-map

Of course, there was an appropriately configured interface at the other end of the tunnel as well. The tunnels came up, and appeared to work just fine, until we added the keepalive statement. (The keepalive statement is required for the tunnel to report an actual up/down status, necessary for HSRP interface tracking.) Then they went down and stayed down.

A “debug tunnel” statement showed that the keepalives were being sent, but none were being received. Thinking perhaps the IPSec configuration was incorrect, I removed the “crypto map” statement from the tunnel interface. It still didn’t work.

After reviewing the configuration again, I began to suspect an MTU issue—the “show int tun0″ output listed an MTU of 1514. I consulted with a Cisco expert (recently obtained his CCIE), and he confirmed that it was most likely an MTU issue. So I modified the configuration to look like this:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 ip mtu 1400
 keepalive
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1

At that point, the tunnel finally came up and I was able to pass traffic through the tunnel. I re-added the “crypto map” statement to enforce encryption, and the tunnels promptly went back down again.

Once again, debug output saved the day. The output from a “debug crypto” statement was constantly reporting “packet too small”. A search of the Cisco web site turned up a result (I can’t find it now) that indicated a bug within IOS and suggested the addition of a “tunnel key” statement. So, I modified the configuration again:

interface Tunnel0
 description GRE tunnel to other location
 ip address 192.168.254.1 255.255.255.252
 ip mtu 1400
 keepalive
 tunnel source FastEthernet0/0
 tunnel destination 172.31.254.1
 tunnel key 12345
 crypto map tunnel-ipsec-map

With this configuration, the IPSec/ISAKMP SAs were established and the tunnels came up, passing traffic as expected. The debug output showed no crypto errors, and keepalives were being sent and received. Success!

Tags: , , , ,

Cisco PIX VPN and Active Directory Integration

Tuesday, November 22, 2005 in Interoperability, Networking, Security by slowe | 32 comments

Rather than publishing this information in PDF form on my business website, I’ve decided to try something new and post it here as a blog entry. So, here goes.

This information assumes that you have some experience with the Cisco PIX firewall (i.e., you know how to enter configuration commands and have a basic idea of what the configuration commands actually do) as well as some experience with Windows and Active Directory.

With that information in hand, let’s get started.

Configuring the Cisco PIX

First, we’ll need to setup the PIX firewall. Use the commands below to configure the PIX for PPTP-based VPN connections that will authenticate against an Active Directory back-end.

ip local pool vpn-pool 10.10.10.1-10.10.10.254
aaa-server vpn-auth inside host 10.10.10.5 secretkey
aaa-server vpn-auth inside host 10.10.10.6 secretkey
aaa-server vpn-auth protocol radius
vpdn group vpn-pptp-group accept dialin pptp
vpdn group vpn-pptp-group ppp authentication mschap
vpdn group vpn-pptp-group ppp encryption mppe 128 required
vpdn group vpn-pptp-group client configuration \\
   address local vpn-pool
vpdn group vpn-pptp-group client configuration \\
   dns 10.10.10.5 10.10.10.6
vpdn group vpn-pptp-group client configuration \\
   wins 10.10.10.6 10.10.10.5
vpdn group vpn-pptp-group client authentication aaa vpn-auth
vpdn enable outside
sysopt connect permit-pptp
access-list acl-nat0 permit ip 10.10.1.0 255.255.255.0 \\
   10.10.10.0 255.255.255.0
nat (inside) 0 access-list acl-nat0

(Note that I have placed a backslash to indicate text that is wrapped onto two lines here but should be entered all on a single line in the PIX configuration.)

In this configuration, replace the IP addresses on lines 2 and 3 (the “aaa-server vpn-auth” commands) with the IP addresses of the servers running Internet Authentication Service (IAS) on Windows. See the next section for more information on configuring IAS.

On those same lines, replace the text “secretkey” with the RADIUS shared secret that will be used when configuring the RADIUS/IAS server in the next section.

Likewise, replace the IP addresses on lines 9 and 10 (the “vdpn group vpn-pptp-group client configuration” lines that pass out the DNS and WINS servers to VPN clients) with the IP addresses of your DNS and WINS servers, respectively.

That should do it. Save the configuration to the PIX and then move on to configuring IAS.

Configuring Internet Authentication Service

Before doing anything else, create a new global security group in Active Directory. Call it something like “VPN Users” or similar. We’ll use this group later as an additional security check in validating VPN connections.

Next, install IAS using the Add/Remove Programs icon in Control Panel. Once it has been installed, launch it from the Administrative Tools folder on the Start Menu and we’ll proceed with configuring it for authenticating VPN connections to the PIX firewall.

First, we need to grant IAS permission to read dial-in properties from user accounts in Active Directory. To do this, right-click on the “Internet Authentication Service (Local)” and select “Register Server in Active Directory”. Select Yes (or OK) if prompted to confirm.

With that done, we can now configure the PIX firewall as a RADIUS client. Right-click on RADIUS Clients and select New RADIUS Client. In the wizard, specify the IP address (or DNS name) of the PIX firewall’s internal IP address and the shared secret. Note that this shared secret is the same secret key specified in the PIX configuration above. RADIUS clients use this to authenticate to RADIUS servers, so make it a reasonably strong password.

Now create a remote access policy. Right-click on Remote Access Policies and select New Remote Access Policy. In the wizard, specify a name, select to create a custom policy, and then add the following conditions to the policy:

  • NAS-IP-Address: This will be the IP address of the PIX firewall’s internal interface. This helps to ensure that this policy only applies to VPN requests from this firewall and not from any other RADIUS client.
  • Windows-Groups: This should be the security group created earlier. Any user that should be allowed to authenticate on a VPN connection will need to be a member of this group.

The rest of the policy should be very straightforward. Make this policy the first policy (using the Move Up/Move Down commands in the IAS console), add a user to the group created earlier, and then test your connection. Remote systems attempting to connect via PPTP should now be able to authenticate the VPN connection using their Active Directory usernames and passwords.

Although this was written from the perspective of authenticating PPTP connections, the process should be very similar for IPSec VPN clients as well.

Tags: , , , , , , , , ,