Archive for the 'Solution Writeups' Category

Page 3 of 4

Outlook 2003/2007 SQL Search Folders

Outlook Search Folders can have a SQL-like structure for filtering the contents. I wanted a search folder that would show me anything in any folder over X months old, since my office blocks the use of .pst or archive’s, I needed a semi-automated way to clean things out of project folders and the like.

  1. Create the search folders and focus them on just the mail folders you want to search, don’t worry about the filter so just chose a simple one.
  2. Outlook 2003 users will see the SQL tab when customizing the search folder, but it’s hidden and annoying in 2007. Thanks to Andrew Delin for pointing us to how to see the SQL tab in the “customize this search folder” screen: basically customize your button bar and add View>Filter as a button. Then click on a search folder and click the Filter… button to see a SQL tab for entering this info.
  3. I wanted to search back six months, so this is my sql statement. the number is the seconds from today (60s*60m*24h*6m):

“DAV:getlastmodified” <= today(-15552000)

Another cool search folder filter based on conversations over at on20.net. More date examples at Andrew Delin’s WebLog.

Setup for Using Your Verizon Wireless XV6700 Pocket PC Phone as an Internet Modem

Setup for using your Verizon Wireless XV6700 phone as an Internet modem (using EV-DO or 1xRTT) over Bluetooth or USB with Windows XP (may work with Sprint PPC-6700 and other HTC phones as well)

Update August 2009: Much of this information is out of date.  Verizon Wireless now blocks  you unless you pay up, and supports tethering with their windows app VZAM.

This how-to is designed for someone who has a Windows XP (32-bit only) computer and a new 6700 series phone, and wants’s to get everything setup from start to finish. This document was written in Summer 2006 as a reminder to me on how to setup my laptop for Internet using my Verizon Wireless phone, all the other fluff is for your benefit. I ended up reinstalling Windows eight or so times in the last year due to experimentation with Vista betas, Windows XP x64 (64-bit), etc. and was tired of re-learning this process every time.

Disclaimer: as is most everything on the Internet and the blog-o-sphere, this has no warranty assumed or implied with it. Do not blame me if your carrier doesn’t like what you’re doing and charges you extra or disconnects your service because these procedures below are against your contract or EULA.

Things I ought to mention first:

  • There are three ways to connect your 6700 phone to a computer: Infrared (IrDA), USB, or Bluetooth. I didn’t test the Infrared since the other two seem much more prevalent and reliable.
  • This didn’t work for me on Windows XP x64. I have a Belkin Bluetooth USB Adapter (F8T003 v2) and used the built-in x64 drivers to link the phone to the computer. But when trying to enable the Dial-Up Networking Bluetooth profile, I would always get error or unresponsiveness, making me think the BT stack in x64 isn’t as refined or tested as 32-bit. You may get better results with other Bluetooth adapters. I also learned that x64 doesn’t have a 64-bit Infrared driver and hours of Google searching shows dozens of people with the same issue and no resolution. Lastly, the .inf file that is used below to install the phone as a USB modem is 32-bit only as well. In the end, I couldn’t get any method for emulating a modem to work on x64/64-bit Windows. I hope this will not be the case with Windows Vista x64.
  • I found that after using this setup for 6 months, I use both Bluetooth and USB depending on the situation. If your phone has a full battery, then Bluetooth is easier (phone can stay in your pocket). But, using Bluetooth and the data connection will wear your phone battery down in a few hours; so by plugging in the USB cable you can actually charge your phone off your computer while you use the connection. If you’ve got a short laptop battery, Bluetooth may still be the best option, so I recommend setting up both and choosing which one to use based on the situation. It sucks to be on the road and have to figure this stuff out offline.
  • With Verizon Wireless (not sure about Sprint), they currently disable this ability to use a pass-through data connection. Directions below will change these settings on the phone, but once you do this you’re supposed to pay Verizon Wireless $60 a month for your phones data plan (rather then the $45 a month unlimited phone data plan). Verizon Wireless calls this BroadbandAccess Connect and it may not be obvious on their site as to how this affects you. I have meetings with Verizon Wireless data sales people due to my job, and was told that it’s not easy for them to tell if your using your phone with a computer; but if they see very high data rates constantly, that they will want to bump you up the $15 extra dollars (the idea is that a computer will use the connection much more then a phone would on it’s own, and that the $45 unlimited plan is only designed for phone-originated data connections).
  • Speed results in Hampton Roads, Virginia (Southeast Virginia) average 414 kb/s down and 115 kb/s up. This was with 90% signal strength (using Microsoft Voice Command answer to what is my signal strength), and being stationary in my home the whole time. 6 tests were done using http://www.speakeasy.net/speedtest/ to Washington, DC over an hour (on a Sunday night) where the min was 334 kb/s and max was 538 kb/s. I found no noticeable difference using USB or Bluetooth, but did find better results using specific driver settings, which are found below.
  • Wmodem is an app on your Pocket PC phone that allows you to use it as a modem device for a computer. Details on how to set it up are below; but some explanation on it is in order. Before you can use this app, you need to disconnect any existing data connection (each time). So if you have ActiveSync setup, or if you just recently used the phones data connection, you’ll see the yellow box lit up in wmodem when you first run it (but you haven’t yet hit the Start button in wmodem). You need to stop any other exiting data connections on the phone before selecting Start in wmodem, as this program monopolizes the data channel.
  • EV-DO and 1xRTT are your options for Verizon phones at the moment. I have been in a vehicle at 70mph using EV-DO (as a passenger only :P ) and it works fine, even as it falls back to 1xRTT. Obviously the speed difference between the two is very noticeable but still usable.
  • Proper device settings for USB modem in XP (or Bluetooth modem in XP). Once you install the drivers for either scenario below, make sure that the speed setting in your dial-up profile is set to a port speed of 230400 and hardware flow control and compression are on. These settings gave me the most consistant speeds above 400kb/s. In the end, none of these settings may matter, but they don’t hurt.

The One-Time Setup on the Phone to Enable Data Pass-through
This is to allow the phone to accept data/modem connections from a computer. With Verizon, they turn this ability off by default, so you’ll need to enable it the first time.

  1. Go to the PHONE application (hit the green phone button on the XV6700)
  2. Enter ##3328873 (or ##feature) and press TALK (or Send)
  3. Enter six zeros for the code (000000)
  4. Now Enable both the BT DUN and Wmodem
  5. Tap OK several times and OK to soft reset your device
  6. Once restarted, look for wmodem in the \windows folder on the device. If you can’t find it be sure in File Explorer to select “show all files”.

Additional Setup for Using Bluetooth Dial-Up Networking

  1. Pair up phone and XP Bluetooth
  2. Go to properties of phone Bluetooth device in XP’s Bluetooth Settings and enable the Dial-Up Networking profile, this will install XP’s Bluetooth Modem driver.
  3. Create a DUN (Dial-Up Networking) profile in Windows XP and use the newly created Bluetooth modem device rather then your standard telephone modem device.
  4. Phone number is #777, username is XXXXXXXXXX@vzw3g.com, password is vzw (X’s are your wireless phone number)
    Now just launch the newly created DUN in XP like you would normally dial-up over a standard modem.

Additional Setup for Using USB Dial-Up Networking

  1. Start wmodem on your phone and set it for USB
  2. Plug in the phone via the supplied USB cable to the computer
  3. XP will try to install the new ‘usb modem’ it sees, if it gets an error, just unplug and try again
  4. Once it asks you for a driver, point it to the .inf file CDMA1X_USBMDM.INF (you can find this file all over the Internet, often bundled with a .exe for starting the connection, but don’t use the .exe, as it’s old and unnecessary, and I didn’t have the best speed test results with it.) This will finish your modem install in XP and it will show up as a new device in Device Manger.
  5. Create a DUN (Dial-Up Networking) profile in Windows XP and use the newly created USB modem device rather then your standard telephone modem device.
  6. Phone number is #777, username is XXXXXXXXXX@vzw3g.com, password is vzw (X’s are your wireless phone number)
  7. Now just launch the newly created DUN in XP like you would normally dial-up over a standard modem.

Short list for connecting each time you want to use it (Bluetooth or USB)

  1. Disable ActiveSync on the phone (or stop data connection)
  2. If using Bluetooth, enable Bluetooth on the phone
  3. Run Wmodem and click Start for either USB or Bluetooth
  4. Either plug in the USB to computer or enable Bluetooth on Computer
  5. Connect the Dial-Up Networking profile you created on the computer, ensuring it’s using the proper modem device for your scenario

Working with NTP and Windows Time Service

For the purposes of this document we will only be talking about Windows 2000 and newer Microsoft operating systems. We will also mostly assume that these computers are apart of the same domain, except where noted, as NTP is unmanaged in a non-domain environment and should just be setup for each computer to get time from the Internet.

Windows Time Keeping
The Windows internal clock ticks once every 10 milliseconds, so no windows clock will be more accurate then 10 milliseconds.

Windows domains use SNTP (Simple Network Time Protocol), a basic version of NTP. The SNTP protocol ensures that all clocks in an enterprise (an entire Active Directory Forest) are within 20 seconds of one another, and all clocks in a site (Active Directory site, usually a single physical location) are within two seconds of one another.

W32Time Service
The Windows service that controls time is W32Time. It auto starts on all domain computers. On domain controllers, it runs a SNTP server on TCP port 123. On non-domain computers (aka stand alone) it does not auto start.

By default all computers in a domain use the ‘domain hierarchy’ to sync time. If a computer is not apart of a domain, then it must be configured manually. All domain members get their time from domain controllers. All domain controllers get their time from the DC who has the PDC Emulator role. All PDC Emulators of sub-domains get their time from the root domain PDC Emulator.

W32Time attempts synchronization every 45 minutes until the clocks have successfully synchronized three times. When the clocks are correctly synchronized, W32Time then synchronizes at eight-hour intervals, unless there is a failure to obtain a timestamp, or a validation failure. If there is a failure, the process starts over from the beginning.

If a computer, upon time syncing, finds its clock to be off by more then 60 seconds, it will log an event in the System Event Log.

Time Keeping Security
Windows uses Kerberos for authentication in a domain. Kerberos requires timestamps (and accurate time) to properly authenticate. By default, if a computer is over 5 minutes off from the Kerberos domain controller it wants to authenticate with, it will be denied authentication with an error of “clock skew too great”. Look below for how to change the time limit.

Once a client requests the time from it’s domain controller, the domain controller then returns the required authentication in the form of a signed 64-bit hash of the time information. If the returned time is not signed or is signed incorrectly, the time is rejected.

If a client is manually configured to access time from an NTP time server outside of the domain hierarchy, the SNTP packets sent between the client and the time server are not authenticated and therefore are not secure. This is how the PDC Emulator gets its time. This is also how any non-domain computer gets their time.

Time Stratum
Stratum is the term used to describe the hierarchy of time servers. A SNTP server with a lower number ‘stratum’ is considered to be of higher accuracy and closer to the ‘true time’. The final ‘root’ server, or Stratum 1, will probably be a UNIX based box on the Internet that your Stratum 2 server (most likely the PDC Emulator of your root AD domain) will sync with.

Here is the path computers will take to get their time. A member of one Stratum level will only try to sync with a server (not workstation) in a lower numbered Stratum.

  1. External NTP time source
  2. PDC emulator of the forest root domain
  3. Domain controllers in the forest root domain or PDC emulators in child domains
  4. Workstations and member servers in the forest root domain or domain controllers in child domains
  5. Workstations and member servers in child domains

Settings and Commands

Set SNTP Master Manually
To prevent the root SNTP server in your active directory from hopping around with the PDC Emulator role, you can set the registry value ReliableTimeSource on any domain controller, making it the master SNTP server rather then the PDC Emulator for that domain. The real world purpose of this it to set a domain controller in the root domain of the forest to this value, and then set it’s external sync source using ‘net time /setsntp:servername.com’. Otherwise, you would have to run the net time command every time the PDC Emulator role changed in the root domain.

HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
Entry Name: ReliableTimeSource
Data Type: REG_DWORD
Value: 1

Change External Time Source
To change the PDC Emulators external time source (or the external time source of any non-domain computer), pull up a cmd.exe console and run these commands:
net stop w32time
net time /setsntp:tick.timeserver.com
or
net time /setsntp:tick.timeserver.com,tock.timeserver.com
net start w32time

Test Time Sync
To test a time sync from any computer in the domain, pull up a cmd.exe console and run:
w32tm –v –test –once

Force Time Sync
To force any computer to sync now, run:
w32tm –s computername
(leave out computername for localhost)

Disable External Time Source
If your domain doesn’t have Internet access, or you just want your root domain PDC Emulator to consider itself the total master of all things time, you can set the following registry value so that it will stop trying to sync with an external time source (or stop complaining to the Event Log that it doesn’t have a time source set).

HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
Entry Name:Type
Data Type: REG_SZ
Value: NoSync

Time Skew
To change the “time skew” of a domain you need to edit the Domain Security Policy from a domain controller. Look for ‘Kerberos Policy’ under Account Policies. Change the value ‘Maximum tolerance for computer clock synchronization’. Increasing this value will reduce security on your network, but may be necessary if you sync over slow and unreliable links. Decrease this time value to reduce the likelihood of a ‘replay attack’.

More Information

The Windows Time Service

http://www.microsoft.com/windows2000/docs/wintimeserv.doc

Controlling Bandwidth For Your Wireless Network Using FreeBSD and DUMMYNET

Scenario: you have a wireless AP that you allow someone to access. You don’t have unlimited Internet bandwidth, so you want to limit your ‘clients’ bandwidth to your network and the Internet. You have a very low budget. You have a free weekend. You have an old pc with two network cards.

We will be using FreeBSD 4.8 (should work with any 4.x) to make an Ethernet bridge between your wireless network and the Internet, and then using DUMMYNET so you can limit the bandwidth from your wireless access point by IP or MAC address.

DUMMYNET (aka ‘a traffic shaper’) is a kernel add-on to ipfw. ifpw is the FreeBSD default firewall package, pre-built into the kernel. DUMMYNET allows you to just add firewall rules into ipfw that will basically ‘slow the packets down’ in various ways (using WF2Q+: Worst-case Fair Weighted Fair Queuing) and the end result is you having control over the bandwidth and latency of data per IP or MAC of any host.

Overall Steps:
Install FreeBSD
Rebuild Kernel to support DUMMYNET
Enable bridge for the two NIC’s
Write your ‘pipe’ rules for DUMMYNET
Test and Deploy

(use http://www.freebsd.org/handbook for help on everything here)

  1. Get a Pentium PC or above with two NIC’s, 32mb of RAM, and a 2GB hard drive from your local PC store for $50. (may work with less, but this is my setup)
  2. Boot the box with a FreeBSD 4.8 CD ISO or Floppies from freebsd.org (you only need the first ISO CD). If you don’t have CD drive in the box (I didn’t) then you can make two floppies to boot from and pull the CD over FTP.
  1. A cool thing to do is download the ISO, burn it onto CD, the copy the whole CD to a server that has FTP and enable anonymous access to the CD files so that I can just walk around with two floppies and make little FreeBSD babies. Note that you can actually pull everything down from public FTP servers with just the two floppies, but unless you’re on an OC-3 the local FTP server will be faster.
  • FreeBSD Install
    1. I will mention the major decisions you need to make during install of FreeBSD here. http://www.freebsd.org/handbook does a much better job of describing this process.
    2. Skip Kernel configuration and continue with installation (unless you have a very odd NIC or SCSI card)
    3. Chose Standard Install
    4. At FDISK, hit A to use entire disk and then Q to Finish
    5. Standard MBR
    6. At Disklabel Editor, hit A to auto default, and Q to Finish
    7. Chose Kern-Developer Distribution
    8. Yes to ports install
    9. Exit Distributions menu
    10. Chose method of install, #2 is used to install from your custom local FTP server if you followed my recommendations above. If you chose #2 then enter the URL manually on the next screen, which should just be the hostname.
    11. Now you’ll see your network interfaces listed. Hopefully you see one of the two NIC’s you have installed. You may have to guess as to which one is connected to the network if you’re doing an FTP-based install. Use DHCP if you need it obviously.
    12. Once install has finished: No to network gateway, NO to configure inetd, No to anonymous FTP, NO to NFS Server, NO to NFS Client, NO to select a default security profile, NO to customize system console, YES to setting time zone, NO to Linux binary compatibility, NO to non-USB mouse (you won’t need to use the mouse in console mode), NO to browsing ports collection.
    13. Once install has finished, you need to add a new user and user group. The best way to do this is to first make a group with the same name as your first username, and then make the user and add it to the group you just created. In FreeBSD, you should always make a non-root user for SSH’ing into the box, and users should always be in groups with the same name as their username. Add the user to the ‘wheel’ member group so they can ‘su’ to root after they log in from SSH.
    14. Exit install, it will reboot, log in as root at the console so we can start configuring.

    Recompile Kernel

    We first need to recompile the kernel with bridging and dummynet enabled so they will work when we configure them. Luckily, we had the install program dump the kernel source in /usr/src so we can recompile the kernel. The current kernel (aka GENERIC) is at /usr/src/sys/i386/conf/GENERIC. We need to copy it, edit it, and add the options we need, then compile it and install it.

    (after logging in)

    cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/BRIDGE
    ee /usr/src/sys/i386/conf/BRIDGE

    Now you should be in ee, an editor that’s a little more friendly then vi. Add the following lines around the other ‘options’ lines.
    options BRIDGE
    options IPFIREWALL_DEFAULT_TO_ACCEPT
    options DUMMYNET
    options HZ=1000

    Now compile the kernel and install it. If it’s a P or PII machine, go read War & Peace while it compiles, if it’s sub 2GHz you can just read the first 1/2 of War & Peace.

    cd /usr/src
    make buildkernel KERNELCONF=BRIDGE
    make installkernel KERNELCONF=BRIDGE

    Now reboot and log in.

    Configuring Dummynet

    We need to edit three files to make it all work. You can use ee or vi for all of these. First one is /etc/rc.conf. You will only be giving your ‘internal’ NIC an IP address in rc.conf. This IP will be used for management access only, and this bridge could theoretically work without any IP’s assigned, because it’s acting like a 2-port switch, and NOT a router. Use the following options to make sure the 2nd NIC (connected to your AP) still turns on during boot (NIC’s don’t turn on if they don’t have a network address). Fill the XXX’s with your net info. /etc/rc.conf

    defaultrouter=”XXX.XXX.XXX.XXX”
    hostname=”XXXX”
    #this is the line to turn on the 2nd NIC
    #the xl0 needs to be whatever ifconfig shows you
    #is the device name of your two NICs
    ifconfig_xl0=”up”
    ifconfig_xl1=”inet XXX.XXX.XXX.XXX netmask XXX.XXX.XXX.XXX”
    firewall_enable=”YES”
    firewall_type=”/etc/ipfw.rules”

    You can have other lines in rc.conf if you like. Here are some others that my bridge box has:

    kern_securelevel_enable=”NO”
    nfs_reserved_port_only=”YES”
    # this disables sendmail server but allows mail out
    sendmail_enable=”NONE”
    sshd_enable=”YES”
    # disable usb if you don’t need it
    usbd_enable=”NO”
    # disable inetd which is for ftp and other services
    inetd_enable=”NO”

    Put these lines in your sysctl.conf to enable the bridge. Note that on the last line I entered xl0:1,xl1:1. The xl0 and xl1 are my two NIC’s, found by typing ipconfig and getting their interface names (the same ones in /etc/rc.conf), and the :1 after each says I want both NIC’s to be in ‘bridge group 1’. /etc/sysctl.conf

    # enables bridge
    net.link.ether.bridge=1
    # tells bridge to go through the firewall
    # by default the firewall won’t see bridged packets
    net.link.ether.bridge_ipfw=1
    # tells bridge what interfaces are bridged
    net.link.ether.bridge_cfg=xl0:1,xl1:1,

    The ipfw.rules file is where you do the rest of the work. You create this file to normally apply your firewall rules, but ‘dummynet’, the traffic shaper, is apart of ipfw. So, put your traffic limiting rules in here as well. /etc/ipfw.rules

    #create a ‘traffic lane’ to put people in
    pipe 1 config bw 2M
    #add every connection to the ‘traffic lane’
    add pipe 1 ip from any to any

    This puts all traffic going across the bridge into the same que/pipe and limitless it to about 2MB/s.

    Note that the above configuration puts the traffic in half-duplex mode, whereas if someone is pulling a file at 2MB one way and someone else is pulling a file the other way, then they will have to share that 2MB pipe. But this configuration makes a separate pipe for data in each direction so it becomes a full-duplex configuration.

    ipfw pipe 1 config bw 2M
    ipfw pipe 2 config bw 2M
    ipfw add pipe 1 ip from any to any out
    ipfw add pipe 2 ip from any to any in

    Here is a configuration that will limit IP 192.168.1.50 to 1MB and the rest will flow freely (if packets don’t match a pipe then they won’t be regulated).

    ipfw pipe 1 config bw 1mb/s
    ipfw add pipe 1 ip from 192.168.1.50 to any
    ipfw add pipe 1 ip from any to 192.168.1.50

    This configuration adds the whole 192.168.2 subnet to the pipe and limits it to 300Kb/s.

    ipfw add pipe 1 ip from 192.168.2.0/24 to any out
    ipfw pipe 1 config bw 300Kbit/s

    A REAL WORLD Example:
    I allow my friend to access my DSL from his house across the street using some wireless gear. I tell him to use DHCP and then hard code his MAC in my dchp server so he get’s the same IP every time (or just have him statically assign it). I know he will be downloading stuff from my ftp server in my room, so I don’t want him maxing out my wireless link so that I can’t use it from downstairs on my laptop, so I want to limit him to about half or so of my wireless bandwidth on my 802.11b access point. The real world speed of 11b on a good day is almost 6Mb/s, so I will limit him to 3Mb/s. Since wireless is a half-duplex technology I will add his in and out traffic to the same queue. I stick this box between my AP and my network and use the following lines:

    Put the pc between your wired network and the Access Point.
    Smile at your accomplishment.

    Note: To add Firewall functionally to this box you will need to make it a router. A limitation of ipfw seems to be that in bridge mode, it can handle firewall rules OR dummynet rules, but not both. Turning this box into a router and adding the line below to your /etc/sysctl.conf will allow packets to flow through the pipe rules and firewall rules.

    net.inet.ip.fw.one_pass: 0

    If you did do this then a lot of this document would be void, but you could take the dummynet lesions learned and apply them to a traditional firewall with dhcp/dns and all the typical services and slap this between your wireless access point and you. It would get complicated quickly, but hey, it’s a great idea. Maybe that’ll be my next project.

    Other things you could do to make this sweeter:

    • add your email address to /etc/mail/aliases as the ‘root’ so you get daily emails about the health of your new traffic shaper.
    • install the webmin port for easier remote management… of something.
    • install apache port and mrtg port to graph the packets used over your bridge.
    • even better: install ntop port for a look at what’s really going on ;)
    • make really fancy dummynet rules, like a cron job that applies different rules at different times of day giving users more bandwidth at night or during your working hours when your not around…
    • References:
      The creator of Dummynet for FreeBSD

      http://info.iet.unipi.it/~luigi/ip_dummynet/

      FreeBSD Handbook

      http://www.freebsd.org/handbook

    Enabling Preshared Key IPSec: Network Encryption for a Home or Small Business

    Audience & Scenario:
    You have more then one computer on a small business or home network. Wireless may or may not be involved. All Computers (that you want to protect) are Windows 2000 or Windows XP. You would like to encrypt your file sharing and communication traffic between these Windows PCs without a lot of work. You would like this all to be seamless after you’ve initially set it up.

    Summary of Tasks:
    We will be using IPSec with a private ‘shared key’ to encrypt all traffic between these computers. This will greatly increase the security for wireless networks because someone will no longer be able to ‘sniff’ your packets from a wireless computer and see what data you are passing back and forth between computers, which is all normally in clear text on a open wireless connection.

    What is IPSec:
    IPSec is a standard specification that allows computers, when enabled and configured, to communicate using TCP/IP with authenication and encryption to protect the data inside each packet. The most popular use for IPSec is for IPSec VPN’s, but this feature is available to any Windows PC 2000 or XP, and doesn’t require a VPN to work. IPSec also normally uses x509 Certificates to encrypt and validate the data, but this function requires a much more complicated configuration. We will be implementing a shared key version of IPSec that doesn’t require certificates or any of the complicated setup. This is not the most efficient or secure way to use IPSec, but it’s better then NOT using it.

    What this Doesn’t Do:

    • We will have to enable IPSec in explicit mode, meaning that it will ask to communicate with another computer securely, but if the other computer doesn’t have the private key it will still allow communications without IPSec. This means that any traffic to the web, or any host without IPSec configured in this way will be unencrypted, and subject to sniffing.
    • This doesn’t not keep people from accessing your network or systems. This is not a replacement for a firewall, or using WEP, WPA, 802.1x, and/or MAC filtering on your wireless access point, nor is it a replacement for strong user passwords. This is an ADDITIONAL step that can be taken to secure your network traffic from onlookers. There is no substitute for ‘boundary access control’.

    Steps:

  • On the first computer, create a text file and type random keyboard characters into it until you have at least 100 characters. This will be your ‘key’ or password that each computer will use to communicate. The longer the key the better. Save this file on a CD-R or floppy so it’s not easy accessible to anyone. You can always print it out for a backup as well.
  • Open the Local Security Policy. In XP, you can find this in the control panel under Administrative Tools (be sure the control panel is in classic view).
  • Right Click ‘IP Security Policies on Local Computer’ and select ‘Create IP Security Policy’
  • Name your security “Shared Key IPSec” or something similar.
  • Leave the ‘Activate the default response rule’ checked.
  • Select ‘Use this string to protect…..’ and copy your preshared key that you saved in a text file into this area.
  • Uncheck Edit Properties and select Finish.
  • You have now enabled IPSec to encrypt traffic on that pc to any pc that requests IPSec be used and also has that preshared key. You now need to do these same steps on each pc that you want to communicate via IPSec.

    References:

    Using IPSec in Windows 2000 and XP, Part One

    Using IPSec in Windows and XP, Part Two

    Using IPSec in Windows 2000 and XP: Part Three

    HOW TO: Configure a Preshared Key

    Subscribe

    Twitter Updates