First, what you will need:

• A knowledge of how to install pfSense – This guide assumes you have installed pfSense before. If you have not, look at the detailed instructions on the pfSense wiki.
• 1 Symantec 5420 Security Gateway – these can be found secondhand since they are discontinued
• 1 IDE HDD (Hard Drive)
• 1 computer that can boot from CD – you will not need this after the install is finished
• 1 computer with a serial port and a serial cable – this can be the same computer that you boot with but must have an OS

1. Burn a copy of the latest stable version of pfSense – I chose 1.2.3-RC3 which I have used and is quite stable.
2. Open the case of the Symantec 5420 and remove the HDD and the CF-to-IDE adapter. Put them both aside in case you want to revert to the Symantec system at some point.
3. Take a HDD that can be erased and put it in your PC – remove all other HDDs from the computer so you don’t overwrite the wrong one and set this one to Master.
4. Boot the pfSense CD and choose “Easy Install” which will give you the kernel option we need at the end.
5. After the files are copied to the hard disk, choose “Embedded Kernel” from the custom kernel choices – this will give us output to the serial port since the Symantec 5420 does not have a monitor output or keyboard inputs.
6. When the install finishes, choose reboot and wait for the computer to shut down. Before it boots again, turn the computer off and remove the HDD.
7. Install the HDD into the Symantec 5420 and ensure the jumper is set to Master.
8. Plug in your serial cable from your running PC and the Symantec 5420 serial port and begin a serial connection with PuTTY or another client program and connect using 9600 8-N-1 settings.
9. Turn on the Symantec 5420 and see the boot screen come up on your terminal window after about 15 seconds. Important: Make sure to choose boot option 2: ACPI Disabled. If it does not boot, go back and check your steps. Ensure you chose the Embedded kernel during install.
10. When the system boots, it should recognize all the hardware and then prompt you to set up the interfaces just like a normal pfSense installation.
11. This step seems to only happen if the drive was not Master in the computer it was installed in. If it doesn’t boot the first time and you get a “mountroot>” prompt it is because the name of the drive was different in the machine you installed pfSense on. As the prompt will tell you, type “?” to see a list of the possible valid partitions. You want to replace the first part (drive name) with what you see in the currently installed and possible drive partitions. If you got the message “Trying to mount root from ufs:/dev/ad2s1a” but your valid drives all start with ad0, then type “ufs: ad0s1a“. Once the computer has booted you will need to take one more step to avoid this in future boots. You will need to edit the file /etc/fstab and change the drive reference (ad0 in the example) to be correct. You can edit this file through the web interface in pfSense or using vi or ee from the shell command prompt. Note: this tip was taken straight from the official pfSense book which I recommend buying if you are using pfSense frequently.
12. Next, to make sure it boots with ACPI disabled by default you will need to make another edit. /boot/device.hints is the file. Add a line at the bottom that says hint.acpi.0.disabled=”1″. Now when the system is booted, boot with ACPI disabled will be default.
    
    *Note that this has been reported to be unnecessary for others. I had no luck with ACPI enabled the first time I tried but that could have been related to something else.

Currently I do not know of a way to get the LCD screen functioning. There is an LCDproc package for pfSense but the driver is unknown. Hopefully this will change soon. Thanks as well to Gnuler (page in spanish – link to english) who seems to be the first record of someone trying out Linux on this box.

http://edmckinzie.spaces.live.com/blog/cns!687C72A5909E4230!232.entry

This problem lies in the fact that Acrobat for some reason has a problem reading or writing to a file on a network share. Since the user’s home drive is connected to the network share, Acrobat will crash every time they try to open a file. Log in with a local user account and everything works great. After figuring out where the problem lay, I found a posting on the Adobe Forums about this exact issue.

What I found there was the following:

1. Log in as a Network User
2. Go to /Users/Shared/
3. If you are on an Intel based Mac create a folder in /Users/Shared/ named 9.0_x86 if you are on a Mac that is a G5/G4 create a folder named 9.0_ppc

At this point you should have created either
/Users/Shared/9.0_x86/
/Users/Shared/9.0_ppc/

4. Go to ~/Library/Application Support/Adobe/Acrobat/ and trash the 9.0_x86 or 9.0_ppc folder contained within
5. Go to Applications/Utilities/ and open Terminal
6. Enter one of the following into the Terminal
If you are on an Intel based Mac enter
ln -s /Users/Shared/9.0_x86 ~/Library/Application\ Support/Adobe/Acrobat/9.0_x86
If you are on a G5/G4 Mac enter
ln -s /Users/Shared/9.0_ppc ~/Library/Application\ Support/Adobe/Acrobat/9.0_ppc
7. Open up Acrobat 9 and it should work!

*bold is my edit*

I found for the link command (ln) I had to actually specify the 9.0 folder. You are basically telling the computer to go to a local directory when it tries to find the user’s files in the home directory which is on the network. I also had to chmod the /Users/Shared/9.0_ppc to 777 because I created the folder with an admin user and the normal user didn’t have rights to make changes. After doing this, it all worked!

As of this posting, it appears the problem still exists and has not been fixed by Adobe even though it has been a known issue for 7 months now.

One of the issues is logging on to the computer when home drives are assigned through the Active Directory profile. As a Domain Admin, when I would sign in I would get the message

The home folder for the user account is located on an AFP or SMB server

and it would not log me in. Upon trying again immediately, it would log me in and my home drive would be mapped just fine! I thought it was annoying but we could deal with it at first but when I had the user try to log in with an account that was not an admin they repeatedly got the error and were not able to log on at all.

A bit of searching led me to an Apple Discussion Forum where I saw that an edit of one file /etc/hostconfig would help. The change is

AUTOMOUNT=-NO-

changing from the YES that is currently in the file. I’m not clear on the exact cause of this but it is definitely a bug. Well, now it works so that part is down. More issues later.

The link below led me to think of Group Policy and I did an rsop.msc on the server to find it was the workstation policy affecting the server. Created a new OU outside the range of the policy which should have been done a long time ago anyways and the problem has been resolved. No more services getting disabled.

My Hint: http://www.tech-archive.net/Archive/Windows/microsoft.public.windows.server.general/2007-05/msg00216.html

The first thing is that the PIX Firewall (with VPN) was already set up when I got here so I won’t get into that configuration. It used to be configured with local accounts for each person who needed VPN and they had a static password. This was a bit cumbersome and insecure as the password never changed. I had used RADIUS to set up the same sort of thing for wireless authentication so I decided to see if I could get it working for the VPN. It took a little doing but I got it.

On Windows Server 2003, you need to install IAS (Internet Authentication Service). Go to Add/Remove Programs (appwiz.cpl) and then select Add/Remove Windows Components on the left side. Select Networking Services then Details, then put a check next to Internet Authentication Service. Select OK and Next and it will be installed. You will find the program under Administrative Tools in the Start Menu.

Once you open IAS, you will need to right click Internet Authentication Service (Local) and select Register Server in Active Directory. This will add the computer to a security group in Active Directory and register the service. Next, right click on RADIUS Clients and select New Radius Client. Here, you will put in the info about your PIX device. Now, even though there is an option in Client-Vendor for Cisco, we will leave it at the default value of RADIUS Standard. Here, you also choose a shared secret. I strongly recommend using a very long string of numbers, letters and symbols. You will only need to enter this here and in the PIX one time and then you can forget about it so don’t worry about making it something easy to remember. One final important note on this step is to leave the box unchecked for Message Authenticator attribute.

Next go to the Remote Access Policies window. Right click and select New Remote Access Policy. Now, I’m going to suggest you do it a little differently than I did originally but it will save you making a few changes later. Instead of using the wizard, select Set up a custom policy. You can name it something like “Allow VPN Access”. Now, in policy conditions select NAS-IP-Address and then enter the IP address of your PIX. The second attribute we’ll select is Windows-Groups. You will need to have created a group in Active Directory first before you can select it so create one called “VPN Access” or something similar. This is the security group you’ll place all users who you want to have access. If a user that does not have access tries to use it when they are not in the group it will fail. After you have added the group, click next and you will be finished. Note the order of the policies — the server will attempt to match each rule starting with the first and if it matches the default rule that denies connections first then it won’t even evaluate yours.

Now that you have your rule in place, open it up for more details. Click on the Advanced tab then Add. Here, you want to add Ignore-User-Dialin-Properties and set it to True. This tells IAS to ignore the properties of each user in their profile which gives them dial-in privileges. I assume this was a previous way of configuring remote access that is not used much anymore. Having users in the security group you created earlier controls the permission of users connecting. Next, go to the Encryption tab and select every encryption but the no encryption box. Then on to Authentication and choose only Unencrypted authentication (PAP, SPAP). Now, this last one with no encryption — I tried very hard to see if there was another way because I don’t want any credentials floating around in plain text but I didn’t see a way. I’m no security expert but when I analyzed some traffic establishing the connection, it looks like the pre-shared key we set up before encrypts the authentication so it is in plain text but only inside of an already encrypted tunnel so it should be safe. Feel free to correct me because I’m still learning about VPNs. After that setting you should be done with the IAS setup.

Now for the PIX. For this I used the PDM interface. I know the true Cisco experts will prefer the command line and I do for switches usually but for the VPN I’m sticking with the PDM interface for now. Once you are logged in, go to Configuration. Once there, select the System Properties tab and then navigate to the AAA category. Under AAA Server Groups you will see RADIUS among others. The only thing I set was Dead Time to 0. If you have more than one RADIUS server you may want to set this to 10 minutes or so because it is the time it will consider a server dead if it can’t contact it and then it will use another server during this time period. On to AAA Servers. Click Add and select RADIUS for the group, inside for the interface, the IP address and also your key that you created back in IAS. Make sure you are applying these settings as you go. Next, we move to the VPN tab and select the IKE category. Find the XAuth/Mode Config and edit the outside interface. Here you’ll select RADIUS for server group and if you want you can check the box to use LOCAL accounts when the RADIUS fails. If for some reason your RADIUS server goes down, you could connect using a local account (such as administrator). This would mostly benefit the admins who know the password as other users wouldn’t know what to type. However, if you have a weak password I suppose it could be a security risk. After you have that set you can apply then save the changes to the PIX.

There is always troubleshooting of course. In the PIX, you can click the Monitoring icon and then view the PDM Log. This should show you when a RADIUS lookup is attempted or if it is not then what is. In IAS you’ll want to look under your normal event logs in the System setting. You will see IAS as Source and you can see what policy is matched. If your policy is not being matched then you need to find out why. It does give you good information such as the IPs, user-name, the authentication and encryption being used. If any of those do not match you may see it is being matched against another Policy-Name and that will give you some clues.

How to do it: While in the game, press Alt + Up Arrow to switch the menu between the bottom of the screen (default) and left of the screen.