1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Completed an IPSec session from MacOS 10.4 to WRV54G

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by tji, May 6, 2005.

  1. tji

    tji Network Guru Member

    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[32]: packet from 24.XX.YYY.184:500: ignoring Vendor ID
    May 6 14:09:33 router.work.com 2005 monkey May 6 19:09:33 pluto[32]:
    "ips50"[1] 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[32]:
    "ips50"[1] 24.XX.YYY.184 #163: OAKLEY_SHA is disabled. Attribute
    May 6 14:09:34 router.work.com 2005 monkey May 6 19:09:34 pluto[32]:
    "ips50"[1] 24.XX.YYY.184 #163: Main mode peer ID is ID_IPV4_ADDR:
    May 6 14:09:34 router.work.com 2005 monkey May 6 19:09:34 pluto[32]:
    "ips50"[1] 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[32]:
    "ips50"[1] 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[32]:
    "ips50"[1] 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[32]:
    "ips50"[1] 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
    - 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.
  2. tji

    tji Network Guru Member

    Okay, I ran over to my local coffee shop with WiFi (Dana Street Coffee Co. in Mountain View, for other Silicon Valley-ites).

    After doing the wget command from QuickVPN to authenticate myself, I grabbed the password, stuffed it into IPSecuritas, and started the IPSec connection. The connection was up quickly, and functioning fine...

    The wget command is:
    wget --output-document=- https://userid:passwd@wrv54g.tji.com/StartConnection.htm?version=1?IP=

    Note, I use "--output-document=-" to output to STDOUT rather than a text file, making it easier to cut & paste it into IPSecuritas.

    My next step will be to see what I can kludge together to automate the process. Currently, I have to change my IP address in the wget command, copy the preshared key that is returned, and start IPSec. Some shell scripting should be able to streamline that process.
  3. DocLarge

    DocLarge Super Moderator Staff Member Member

    Nice to see someone else finally tried this. Here's a link I posted in regards to using the wget command through greenbow that Chris547 came up with out about a month ago:


    He put "two-and-two" together and realized you could use the "wget" command through DOS from the quickvpn client directory and then take that information and post it inside of greenbow vpn settings. The result? You can now get around the NAT-T issue and connect from behind another router via quickvpn properties used with Greenbow to a WRV54G (provided you have a user account on it).

  4. tji

    tji Network Guru Member

    Also, here are some of the basics from my MacOS config, using IPSecuritas to set up the IPSec stuff.:

    Mode of Operation: Host to Network
    Remote IPSec device: (external IP address of WRV54G)
    Remote Network: (or whatever your LAN address is)
    Exchange Mode: Main

    Phase 1
    Lifetime: 28800 seconds
    DH Group: Mod1024
    Encryption: 3DES
    Authentication: MD5

    Phase 2
    Lifetime: 28800 seconds
    PFS Group: Mod1024
    Encryption: 3DES
    Authentication: HMAC MD5

    Local Identifier: Address
    Remote Identifier: Address
    Preshared Secret: (get from the wget output)

    Options (all unchecked except the following)
    Compression Deflate, IPSec DOI, Verify Identifier
    Establish IKE immediately, Auto Start

    Beyond that, the biggest help in debugging the connection is to enable syslog logging output from the WRV54G. Look for the log messages with "pluto" in the text, pluto is the IKE daemon, and will be outputting the results of each step in the IKE negotiation.
  5. tji

    tji Network Guru Member

    MacOS X 10.4 had a problem with IPSec, the performance was very slow, and ping times were ~1000ms.

    The 10.4.1 update has apparently fixed those issues, and IPSec works great now. I use IPSec to the WRV54G I installed at my parents' house, to provide "tech support" for their PC problems via VNC.

Share This Page