I have been occasionally trying to complete an IPSec connection through the WRV54G with my MacOS PowerBook's built-in IPSec capabilities for several months.. Today I was finally able to complete the IPSec SA, and connect sessions to the machines behind the WRV54G. I still need to do some more testing before I can say with confidence that I have a workable solution. But, it's a step in the right direction. The thing that finally got me over the top was finding where the IPSec logs were (duh!). I had the WRV set up to send logs to my Linux box via syslog. But, I had only seen part of the logs -- nothing specific to IPSec. My syslog.conf had a bit of a confusing configuration. I thought it would log everything to /vat/log/auth, but it was instead putting the IPSec messages in /var/log/secure. Once I figured that out, debugging IPSec became much more straightforward (without the logs, you're just thrashing blindly). To do a sanity check, I connected via QuickVPN on a Windows machine. The IPSec logs were: May 6 14:09:33 router.work.com 2005 monkey May 6 19:09:33 pluto: packet from 24.XX.YYY.184:500: ignoring Vendor ID payload May 6 14:09:33 router.work.com 2005 monkey May 6 19:09:33 pluto: "ips50" 24.XX.YYY.184 #163: responding to Main Mode from unknown peer 24.XX.YYY.184 May 6 14:09:33 router.work.com 2005 monkey May 6 19:09:33 pluto: "ips50" 24.XX.YYY.184 #163: OAKLEY_SHA is disabled. Attribute OAKLEY_HASH_ALGORITHM May 6 14:09:34 router.work.com 2005 monkey May 6 19:09:34 pluto: "ips50" 24.XX.YYY.184 #163: Main mode peer ID is ID_IPV4_ADDR: '192.168.1.101' May 6 14:09:34 router.work.com 2005 monkey May 6 19:09:34 pluto: "ips50" 24.XX.YYY.184 #163: sent MR3, ISAKMP SA established May 6 14:09:34 router.work.com 2005 monkey May 6 19:09:34 pluto: "ips50" 24.XX.YYY.184 #164: responding to Quick Mode May 6 14:09:36 router.work.com 2005 monkey May 6 19:09:34 pluto: "ips50" 24.XX.YYY.184 #164: IPsec SA established The main points I picked out of this were: - It used IPSec Main Mode for the connection. Some previous errors I had seen said that the WRV wanted aggressive mode.. So, this was a bit surprising. - Peer IS is ID_IPV4_ADDR. The peer ID is the IP address of the client, not the user name or some other value configured in the SSL exchange used by QuickVPN. I next tried connecting via my MacOS machine. I used wget to authenticate with my client username/password. The output of that gives my the Pre-Shared Key to use for IPSec authentication. I plugged that PSK into my IPSec, and tried to connect. I got this error message: My 6 14:17:31 router.work.com 2005 monkey May 6 19:17:31 pluto: "ips50" 24.XX.YYY.184 #167: peer requested 128800 seconds which exceeds our limit 28800 seconds. Attribute OAKLEY_LIFE_DURATION (variable length) So, make sure your PHASE 1 expiration timer is 28800 seconds or below. Once I fixed that, I was able to complete the IPSec session. A few other items about this setup: - Both the QuickVPN and MacOS IPSec sessions were completed from behind a NAT gateway (which is set up to allow IPSec pass-through). NAT-T is not needed to work through NAT. It just makes it easier, by encapsulating the IPSec packets in UDP. - I wasn't able to complete the MacOS connection until after I had completed the QuickVPN connection. I need to verify the MacOS connection from a different address, independently of QuickVPN, to make sure QuickVPN wasn't doing more behind the scenes to enable the connections. - My IPSec session from MacOS 10.4 had slow performance. But, I think that's a MacOS problem, not WRV54G. I have read other user reports of the same behavior on MacOS Tiger, with other IPSec gateways. - On the MacOS side, I used IPSecuritas to handle the IPsec config. Though, going forward, I might revert to some perl scripts for building the config files -- because they might allow for pulling the derived PSK from the wget/ssl connection. I plan on doing some more verification of this setup. Once I have more information, I'll post it here.