Re: Wifi ipsec freebsd

From: Matthew Faircliff (matt_at_databias.co.za)
Date: 11/27/03

  • Next message: Jens Baedeker: "Ultra 2 SMP stop in probing devices during install" 
    Date: Thu, 27 Nov 2003 09:34:27 +0000
To: Timothy Ham <tham@nth-order.com>

    Hello,

    I too have set up a ipsec secured wireless network and this article
    helped clarify some of the points that were a bit hazy.

    Tunnel vs. transport mode was something I never fully understood. I did
    notice that when using transport mode only the packets between the 2
    participating hosts were encrypted (tcpdump reveals all) and everything
    else (broadcast included) was still in the clear. Your guide has helped
    explain this.

    Well done on a structured, concise article.

    Matthew Faircliff

    On Tue, Nov 25, 2003 at 11:25:34AM -0800, Timothy Ham wrote:
    Date: Tue, 25 Nov 2003 11:25:34 -0800 (PST)
    From: Timothy Ham <tham@nth-order.com>
    To: freebsd-questions@freebsd.org
    Subject: Wifi ipsec freebsd

    After a few days of struggling, I have successfully set up an ipsec
    connection over wifi between a FreeBSD gateway and a Windows laptop.
    Since I had to search for the information I needed all over the net, I
    have written a step-by-step set-up guide to help anyone else trying to
    secure their wifi connection. I hope this is useful.

    Thanks for your attention.

    ---------Begin Guide---------

    FreeBSD Wi-Fi IPsec easy-setup guide
    Timothy Ham <tham (at) socrates berkeley edu>
    Nov 23, 2003

    Version 1.0
    The latest version of this file can be found at:
    http://sahara.lbl.gov/~tham/wifi-ipsec.txt

    0. Abstract
    -----------

    An IPsec tunneling connection was set up between a MS-Windows host
    with wireless ethernet and a FreeBSD NAT gateway. This setup
    allowed the mobile host to have a secure and encrypted connection
    over an inherently insecure wi-fi radio network.

    1. Introduction
    ---------------

    Recently I have purchased a "Wireless Bundle", consisting of a
    wireless NAT router and a PCMCIA 802.11b card, for not a lot of
    money (I love cheap hardware). Being a consumer device, it was
    very easy to set up and to get it working with my existing home LAN.
    But difficulties arose when I tried to secure the connection, and
    also when I tried to protect the rest of my LAN from any intrusion
    through the wireless access point.

    The choice of IPsec over WEP was for me obvious. Besides WEP being
    insecure (secret key can be recovered easily), my PCMCIA card had
    a buggy firmware, which kept dropping connections when WEP was
    turned on. The problem was well documented on various web boards
    and the manufacturer had no updates to fix the problem (I hate
    cheap hardware). As such, I was left with a superior, but harder
    to setup, choice.

    There were some resources available on the web to set up IPsec
    VPN, but none of them were specific enough for my case. As such,
    I thought I would share my experience hoping it will be useful
    for others.

    2. Isolating the Wireless LAN
    -----------------------------

    My existing home LAN was as follows. I had a dual-homed FreeBSD
    NAT gateway with dhcpd running to dole out private IP address to
    any machine connected to the LAN. A guest could come by and connect
    their laptop to the LAN and surf the web. A typical setup.

    The first step was segregating the wireless LAN from the rest
    of my home LAN. I made this easy by installing another ethernet
    card ($10) into the FreeBSD box, and giving it a separate address
    space. For example, my existing LAN was using 192.168.1.x.
    The new ethernet card has 192.168.2.1. With proper firewall
    rules and IPsec, this segment can be isolated from the rest of my
    home LAN.

    Because my wireless access point is sold as a router/switch (it
    was much cheaper than a stand-alone access point--go figure) its
    router functions (DHPCD, NAT) had to be disabled. It had a web
    interface to change its settings. I also gave the wifi net a
    name. The router had 4 ethernet ports labled "LAN", and one port
    labled "WAN". Since I'm just using the wireless/switch portion,
    I connected my new ethernet card (192.168.2.1) to one of the "LAN"
    ports.

    The laptop was given a permanent IP of 192.168.2.10.

    3. Transport Mode vs Tunnel Mode
    --------------------------------

    This part had confused me a great deal because the literature
    out there (including the FreeBSD handbook) mentions IPsec tunnels
    in terms of VPNs--that is, two gateway machines connecting two
    sub-nets over a secure tunnel using a virtual interface gif. So
    at first, I thought what I wanted was a transport layer, that
    encrypted packets end-to-end. But this is *not* what you want.
    All packets between the laptop (host) and the gateway
    (192.168.2.10<->192.168.2.1) were encrypted. However, any other
    packets destined to the rest of the internet were not
    (192.168.2.10->www.yahoo.com). This is not what you want. What
    you *do* want is a encrypted tunnel between the host and the
    gateway that carries packets from the host to the rest of the
    internet.

    Here is what should happen:
    Any outgoing packet from the host to anywhere
    (192.168.2.10->www.yahoo.com) should be encrpyted and encapsulated
    in another packet designated to the gateway
    (192.168.2.10->192.168.2.1). Once the gateway receives the
    packet, it is decrypted and forwarded to www.yahoo.com.

    A returning packet (www.yahoo.com->192.168.2.10) should be
    encrypted and encapsulated by the gateway and sent to the host
    (192.168.2.1->192.168.2.10). The host will decrypt the packet and
    read the contents.

    The existing NAT machinery will handle the private IP address
    translation at the public internet interface.

    4. Setting up the Gateway
    -------------------------

    With the above in mind, here is how the gateway was set up.

    A. Recompile the kernel with IPsec support by adding the following
       to the kernel config file:

            options IPSEC
            options IPSEC_ESP

       Recompile, reinstall, and reboot with the new kernel.
       Add the following to /etc/rc.conf

            ipsec_enable="YES"
            ipsec_file="/etc/ipsec.conf"

    B. Setup the security policy. Create /etc/ipsec.conf with the
       following. In this example, 192.168.2.10 is the laptop host
       and 192.168.2.1 is the gateway interface.

            flush;
            spdflush;
            spdadd 192.168.2.10/32 0.0.0.0/0 any -P in ipsec
             esp/tunnel/192.168.2.10-192.168.2.1/require;
            spdadd 0.0.0.0/0 192.168.2.10/32 any -P out ipsec
             esp/tunnel/192.168.2.1-192.168.2.10/require;

       Run 'setkey -f /etc/ipsec.conf' to use the security policy.

    C. Install and configure racoon.

       Racoon is found in /usr/ports/security/racoon. Make install

       Once installed, set up /usr/local/etc/racoon/psk.txt. This lists
       the pre-shared-keys for your hosts. For example:

               192.168.2.10 SecretKey

       Try to make the secret key hard to guess. A good resource is
       the "Passphrase FAQ" on the web.

       Now, create /usr/local/etc/racoon/racoon.conf. I copied the
       racoon.conf.dist file and changed and modified the "listen"
       directive and the "life time" values in the "remote anonymous"
       and "sainfo anonymous" directives. I set the life time to 24
       hours and 12 hours for "remote" and "sainfo" respectively,
       following suggestions from 'man racoon.conf'.

    D. Start racoon

       Run 'racoon -F -v' as root to have racoon run in foreground
       and display debugging info to the standard output.

    5. Setting up the Windows Machine
    ---------------------------------

    Windows 2000 and XP have similar but slightly different dialogs
    and wizards, but the idea and the final results are the same. I
    put a summary at the end, which is the same in either version.

       - Go to the Start menu and click on Run. Type mmc and <enter>.
       - Select Console (or File)->Add/Remove Snap In.
       - Select Add...
       - Choose IP Security Policy Mangement and click Add.
       - Select Local Computer and click Finish.
       - [In XP, also add IP Security Monitor snap-in]
       - Select Close to close the Add standalone Snap-in dialog.
       - Select OK to close Add/Remove Snap-in dialog.

    You have now added the IP Security Policies snap-in. Now to setup
    a wifi policy.

       - Select IP Security Policies on Local Machine and right click
         and select Create IP Security Policy.
       - Give the security policy a name (ex, wifi). Click Next.
       - Un select Activate the default response rule. Click Next.
       - Un select Edit Properties. Click Finish.

    Now along with Client, Secure Server, and Server, you should
    have a policy called "wifi". Now to set up filtering rules:

       - Right click on IP Security Policies leaf on Console Root and
         select Manage IP filter lists and filter actions.
       - click Add.
       - Name this filter list OutboundIPsec. Then click on Add.
       - Follow the wizard and select My IP Address as the Source,
         Any IP Address as the destination address, and any protocol
         type. Check the Edit Properties box. When the edit
         properties come up, un-check "mirrored". Finish.

    Now there should be one filter in the OutboundIPsec list. Select
    Close. Add a second filter list and name it InboundIPsec,
    repeating the steps above. This time, add a filter with Any IP
    Address as the source and My IP Address as the destination
    addresses.
    Be careful here. There should be two new IP filter Lists, each List
    with 1 rule, not one filter List with two in/out rules. Make
    sure filters are not "mirrored."
    Close everything until you get back to the Console1 view.

    Now to use the filters we've created in the policy:

       - Double click on the wifi policy.
       - Click Add to add new IP Security Rules.
       - Select "The tunnel endpoint is specified" radio button and
         enter in the gateway (ex, 192.168.2.1). Click Next.
       - Select Local area network (LAN). Click Next.
       - Select "Use this string to protect the key exchange", and
         enter the pre-shared-key passphrase from racoon setup above.
         Click Next.
       - Select "OutboundIPsec" IP filter list you just created. Click
         Next.
       - Select Require Security. Click Next.
       - Un select edit properties. Click Next.

    Repeat the above and enter the host (ex, 192.168.2.10) in the
    third step, and "InboundIPsec" IP filter list in step 6. Everything
    else is the same.

    Now that's everything. I'll summarize what you should see here
    (applies to both 2000 and XP).

       - "Console root" has a branch called "IP Sec Policies on Local
         Machine".
       - IP Sec Polocies should have many folders, one of which is
         named "wifi".
       - Double clicking on "wifi" brings up its properties. It
         should have two Rules, both of them checked, and with the
         following properties (which can be seen by scrolling right):

         Property InboundIPsec OutboundIPsec
         ------------------------------------------------------------
         Filter Action Require Security Require Security
         Authentication Preshared Key Preshared Key
         Tunnel Setting 192.168.2.10 192.168.2.1
         Connection Type LAN LAN

    Save the Console by selecting Console->Save As... menu. Name it
    Wifi console.

    5. Testing it out
    -----------------

    First, make sure the gateway is ready. Run 'setkey -f
    /etc/ipsec.conf' and have racoon running in the foreground in
    verbous mode ('racoon -F -v').

    On the Windows machine, make sure the wifi-card can see your wifi
    LAN and have good signal strength. Have the wifi console you
    created open. Make sure the "wifi" policy is Unassigned.
    Also have the services list open by right clicking "My Computer"
    on the desktop, select Manage, and select "Services and
    Applications" -> "Services". It should give a list of all the
    services running on the machine. Have the IPSEC policy agent
    selected (In XP, the name is slightly different). Also, have a
    command prompt open.

    (Note: Windows 2000 has a utility called ipsecmon which can be run
    from the command prompt. In WinXP this utility exists as a snap-in
    which I mentioned above.)

    Ping the gateway from the prompt: "ping -t 192.168.2.1".
    You should be able to ping the gateway at this point.

    Go to the Wifi console, right click on the "wifi" policy, and
    select "Assign". Go to the Computer Management window and right
    click on IPsec Policy Agent and select "restart".

    At this point, you should see lots of debugging messages from
    racoon as the host tries to negotiate keys. The ping command in
    the Windows machine should show "Negotiating IPSEC" for a few
    seconds, after which pings should be returing normally.

    When ping command becomes normal, run tcpdump on the gateway to
    see if the packets are really encrypted by running 'tcpdump -i
    ep0' or 'tcpdump -i ep0 -x -X -s 14400' for more detail. Replace
    ep0 with your wifi interface, of course.

    Fire up your browser and see that all the packets visible on
    the wifi interface are between the gateway and host, and the
    contents are encrypted.

    6. Some Known Issues
    --------------------

    - After setting up everything, the ping and tracert work fine,
      ping packets appear encrypted under tcpdump, but no sites are
      reachable.

      Disable the built-in "IP Firewall" in the TCP/IP setting for the
      wifi interface. The help files say it interferes with VPN tunnels.

    - The ping command returns "Negotiating IPsec" for several seconds
      then "Request timed out."

      Keep pinging with the -t flag, meanwhile, restart the IPsec
      Policy manager service. I'm not sure what causes this, but
      it could take anywhere from a few seconds to few minutes before
      the ping command starts to work.

    - When the connection is idle for a while (minutes), connectivity
      is lost.

      When an IPsec tunnel is idle for a while, it is closed. And it
      could take several seconds to reconnect (see above). I don't
      know of a way to force the tunnel to stay open except by keep
      sending messages through it. I do this by having an ssh session
      open, or having a web page that reloads frequently. Any other
      workarounds (especially at the gateway end) would be welcome.

    7. Conclusion
    -------------

    At this point you should have a secure Wifi connection between
    your laptop and your gateway. Anyone sniffing the access point
    should only see packets going to and from the host and the
    gateway in encrypted form.

    I hope this document was helpful for you. Any suggestions,
    corrections, and tweaks are more than welcome.

    (C) Timothy Ham 2003
    Redistribution of this text is permitted as long as the copyright
    is retained.

    End of File

    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

  • Next message: Jens Baedeker: "Ultra 2 SMP stop in probing devices during install"