August 4, 2005

Cisco PIX to Strongswan

I say Strongswan, but really FreeS/WAN, OpenSwan, no difference I suspect.

I’ve had this problem with Cisco people telling me “well, just put hosts X, Y, and Z in your access list,” when *S/WAN just gives me a single left/rightsubnet parameter. My fears were realized: this means they want a separate connection description in ipsec.conf for each access list entry.

I’m thinking the PIX configuration looks something like (excerpt):

access-list 100 permit ip 10.0.0.1 255.255.255.0 192.168.0.100 255.255.255.0
access-list 100 permit ip 10.0.0.1 255.255.255.0 192.168.0.101 255.255.255.0
access-list 100 permit ip 10.0.0.2 255.255.255.0 192.168.0.100 255.255.255.0
access-list 100 permit ip 10.0.0.2 255.255.255.0 192.168.0.101 255.255.255.0
crypto map mymap 10 match address 100

Which, to me, says “10.0.0.1 and 10.0.0.2 can access 192.168.0.100 and 192.168.0.101.” So your ipsec.conf might look something like:

conn pix-1-1
    also=pix-1
    also=you-1
    auto=start

conn pix-1-2
    also=pix-1
    also=you-2
    auto=start

conn pix-2-1
    also=pix-2
    also=you-1
    auto=start

conn pix-2-2
    also=pix-2
    also=you-2
    auto=start

conn pix-1
    also=pix
    rightsubnet=192.168.0.100/32

conn pix-2
    also=pix
    rightsubnet=192.168.0.101/32

conn you-1
    leftsubnet=10.0.0.1/32

conn you-2
    leftsubnet=10.0.0.2/32

conn pix
    authby=secret
    left=1.2.3.4
    leftnexthop=%defaultroute
    right=5.6.7.8
    rightid=@the.pix.id
    rightnexthop=%defaultroute
    keylife=86400
    pfs=no

Needless to say, this is not a fun-looking configuration. It is long, and can’t possibly scale well.

Some notes:

  • *S/WAN is the left, PIX is the right. This might need to be the case anytime you want to talk to a PIX.
  • At least you only have to have the actual IP addresses listed once. I’m thinking I can make this go better with policies.
  • authby=secret because I’ve never had a PIX admin give me anything other than a PSK.
  • rightid is apparently in some “RSA key”? Per the PIX admin I was talking to. I doubt this, in retrospect, but it is important to use the right ID when talking to the PIX. Don’t forget to list this ID in /etc/ipsec.secrets for the key you’ll be using.
  • Around the same time I started seeing messages about the wrote ID being sent by the PIX (not the IP, as is the default without something like rightid), I also started getting key lifetime errors. The person I was working with said his was explicitly set to one day (86400 seconds). Don’t know if this is a default or not.
  • No PFS on PIX, at least not by default.

AVI to DVD

I wanted to take some completely legitimate AVI files and burn them to DVD so I could watch them on the DVD player/TV in the living room. Up until now I’ve been using NeroVision Express to do this. After burning to DVD with NVE, though, I noticed the DVD audio and video were out of sync (I think the video was delayed compared to the audio).

I dug around all over. There didn’t even appear to be a straightforward way to do this… at least not a recent one, one that didn’t involve command line tools (command line tools, with lots of options, in Windows where I’m not used to this sort of thing). Eventually I did settle upon the AVI to DVD guide at afterdawn.com.

My AVI had Xvid video and two channel AC3 audio. I used VirtualDubMod to extract the AC3 out, then TmpgEnc to encode the video, then Ifoedit to recombine the two into VOBs. But I wanted menus too, so I ended up pointing NVE at the VOBs and used it to actually burn the DVD with a menu. Let me speak about the times involved here: VDM quickly demuxed the stream, TmpgEnc took 12 hours for a 45 minute video, then NVE took a reasonably long time (say, 20-30 minutes?) to “read” the VOB files. Burning took only about 10 minutes. The result? Audio/video were synced, but the AVI was in 16:9 and TmpgEnc encoded in 4:3, so the aspect ratio was off.

Next I tried a similar procedure and instead had a friend use Cinema Craft SP to encode. That encoder was way faster: it only took about 90 minutes to encode the 45 minute clip. (I don’t know the processor in this machine, to be honest, but it was a pretty recent laptop in both cases, almost identical speeds I think.) This time I got the aspect ratio right… I think. The bars at top/bottom (playing 16:9 on my 4:3 TV) didn’t look big enough. Process was the same otherwise. Everything looked fine here.

My next experiment is using VirtualDub-MPEG2 to make a new AVI, using direct stream copy on both audio and video, in hopes that just “remuxing” the AVI is enough to fix whatever NVE’s damage is, then just have NVE start on these “remuxed” AVIs. I say “remuxed” in quotes, because I’m not sure how different the output AVIs are from their source when using direct stream copy for everything. An AVI I transcoded/burned yesterday with this method (VD then NVE), from the same set of AVIs with desynced audio/video, seems to be properly synchronized. For a real test I’d want to go back and try this method on one of the AVIs I know for a fact to be desynced when transcoded by NVE; but encoding takes a long time (probably 2-3 hours for a 45 minute AVI with NVE on multi-pass VBR) and I’m not around all the time to start/stop, eject/insert, etc. So when I get a burn started, I like it to be for something I actually want to watch.

BTW, the AVIs were synchronized just fine when played directly on a PC, so I assume the desynchronization is an effect of the transcoding that NVE does. GSpot and AVIcodec are useful utilities. Everything seems to say the AVIs have 0 delay on the audio stream.