RHEL/CentOS/Linux/OSX Handy Hints

Add rpmforge to yum under CentOS 6

See also: http://wiki.centos.org/AdditionalResources/Repositories/RPMForge

Installing for CentOS 5 is slightly different, see the link above for more info.

Assuming you have root permissions...

Install yum priorities...

yum install yum-priorities -y

Edit the /etc/yum/pluginconf.d/priorities.conf and ensure the following is present:

[main]
enabled=1

Normally, the installer sets the plugin enabled, but it doesn't hurt to check (or know where to turn off the plugin if you don't want it).
You should see priorities plugin in the Enabled plugins list that yum prints when you run it normally.

Some guides don't mention this but do talk about adding the priorities, however, it seems that priorities are not installed by default even under CentOS 6, so you need to install them first.
If they are already installed the install command will do nothing, but they may be disabled in the config file, so make sure you check it.

wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm

Or use i386 instead of x86_64 if you are on 32-bit, which obviously you aren't...

If you want to check the downloads and maybe avoid some warnings, install DAG’s GPG Key:

rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
rpm -ivh rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm

May get a warning, but it should proceed anyway.

Edit the file /etc/yum.repos.d/CentOS-Base.repo and add priorities to the bottoms of all the repo sections:

[base]
priority=1

[updates]
priority=1

[extras]
priority=1

[centosplus]
priority=4

[contrib]
priority=4

The latter two sections are probably disabled anyway, but set them anyway.

Edit the file /etc/yum.repos.d/rpmforge.repo and set the priority for the rpmforge section...

[rpmforge]
priority=6

Then do a yum update -y to cache the rpmforge repo.

Setting the rpmforge repo to a higher priority ensures that it is only used if the other (standard) repos don’t have the package and also ensures that lower priority repos will not be used to update something installed from a higher priority one.

Install virtualbox guest additions into CentOS 6 (also CentOS 5)

This also works for CentOS 5, and resolves annoyances with display resizing (assuming you allowed enough video memory in the first place).

Yes, it really fixes the problem with CentOS 5 display sizing automatically to the window (which is broken without a full guest additions installation).

First you need to add rpmforge to yum so you can install dkms (see previous).

yum update -y
... if the above updates anything to do with the kernel you need to reboot here ...
yum install dkms binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel -y
cd /media/VBOXADDITIONS ... hit tab ...
export MAKE='/usr/bin/gmake -i'
./VBoxLinuxAdditions.run

Then reboot and guest additions should all be working fine.

CentOS and RHEL Access and Permission Problems

Trying to configure mail systems and you're hitting mysterious 'access denied' or 'permission denied' issues, even though permissions allow access? This often happens when trying to get postfix and dovecot to talk to each other.

The problem is most likely SELinux. Most people cop out by disabling SELinux; and if you disable it, it might solve your problem. In some cases, SELinux appears to interfere with access even when disabled - do a full rebuild of the permissions if you seem to have this problem. Check out this guide to CentOS security for information on how to enable and disable SELinux, and how to fix your security without disabling it.

Here is a full guide on SELinux in CentOS.

This wiki on SELinux booleans may also be helpful for the serious SELinux user (e.g. people who don't simply want to turn it off) .

Use sestatus to check your SELinux status.

The setenforce command allows you to change between Enforcing and Permissive modes on the fly but such changes do not persist through reboot.

To make changes persistent through a system reboot, edit the SELINUX= line in /etc/selinux/config to either 'enforcing', 'permissive', or 'disabled'.
e.g. SELINUX=permissive.

To relabel the entire filesystem (this seems to fix some problems where you have changed SELinux status):

# touch /.autorelabel
# reboot 

Users of Ubuntu may experience similar problems due to AppArmor. Problems are usually resolved by setting the AppArmor properties correctly.

Enable or disable SELinux

Edit /etc/selinux/config and look for the line:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing

Yes, the comments in the file say it all, set enforcing to enable it, set permissive to log violations and disable to turn it off completely.

Linux performance stats

Choosing a disc access scheduler

# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
# echo deadline > /sys/block/sda/queue/scheduler
# cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq

Fix postfix policyd-weight cache issues

If you're seeing maillog messages like:
cache_query: $csock couln’t be created: connect: Connection refused, calling spawn_cache()

...then you probably need to delete the socket lock files manually; sometimes this is necessary after a bad shutdown.

Find the LOCKPATH directory:
policyd-weight defaults | grep LOCKPATH
The default location is /tmp/.policyd-weight

Stop the service:
service policyd-weight stop
or
/etc/init.d/policyd-weight stop

Delete everything in the LOCKPATH directory:
rm -rf /tmp/.policyd-weight/*

Restart the service:
service policyd-weight start
or
/etc/init.d/policyd-weight start

Other problems, involving a corrupt cache and bogus cache lookup results can be solved a different way:

Kill the cache daemon:

policyd-weight -k

- should clear all cache entries. Depending on configuration you may want to do service postfix restart afterwards to be sure.

Check the cache status:

policyd-weight -s

Can also try:

policyd-weight -d

to start debug cache daemon.
This can be stopped again using:

policyd-weight -d -k

Reset SQL root password (or any other user)

use --init-file to start it up with:
UPDATE mysql.user SET Password=PASSWORD('<new password>') WHERE User='<user>';
FLUSH PRIVILEGES;
Afterwards, delete the init file.

Edit list of Linux nameservers

Edit the file /etc/resolv.conf and add or remove entries of the form:

nameserver 192.168.1.1

Use service network restart to apply the edits.

Basic configuration of bind9 (named) on CentOS / RHEL 5

The basics:

sudo yum bind9
sudo chkconfig named on

OK, now you've installed bind but want to know where the examples are, or how to set up the configuration files. The bind configuration samples are in:

/usr/share/doc/bind-9.x.x/sample/etc/ and /usr/share/doc/bind-9.x.x/sample/var/

Copy the default configuration files above to /etc/ and /var/named/ respectively. If you are serving several local domains. In addition, I suggest you create a named.conf.local file or something similar that contains all the zones for your system, and include it into your main configuration file.

Comment out the example zone definitions in the internal view.

If you intend to be authoritative nameserver for a zone, add it to your external view using the format show in the example zones in the internal view. You will need to create a zone description file in /var/named, which is beyond the scope of this simple explanation.

The bind executable is in /usr/sbin/named ... to test your configuration before running properly as a service, run with -g to run in the foreground and dump to stdout, -d controls debug level

You should probably also add -u named to run as the 'named' user, because otherwise you will run as the current user, which is almost certainly going to cause problems, even if you are root :)

e.g. sudo named -g -u named

You can use dns-keygen to generate DNS TSIG keys (no, it doesn't need any complex parameters, it just spits out a key to the stdout, or wherever you pipe it).

You will need to edit /etc/named.conf to replace the note about this with a real key if you have a master/slave config. Otherwise comment out that whole key section because you don't need it.

This key (if you use it) is a 'secret', you need to get it to the other machines securely (you copy that key manually into a file on the other machine). It is not a certificate. Normally the key should be kept in a file with no read permission for group or others and included into the main config file, which (allegedly) needs to be globally readable (though I suspect this is not entirely true).

To check a bind config file for errors:

named-checkconf /etc/named.conf

named-checkzone domainname.tld /var/named/db.domainname.tld.zone

Assuming that you have called your zone file db.*.zone

When you've finished configuring, sudo service named start (or restart if you already started it).

Finally, you need to open up the ports for bind9. Traditionally, bind has used port 53, and doing anything else is more likely to cause trouble, despite the 'security benefits'. Ultimately, if you are running bind as anything other than a caching nameserver, then you want people to be able to find you.

You should probably open up both UDP and TCP on port 53. While some will say that UDP is enough, there are some servers that only use TCP, so again, you're asking for trouble if you try to avoid opening it for TCP as well. I can't see any realistic benefit of not opening it for both anyway. If bind has a vulnerability, it's probably not going to be restricted to TCP connections, and returning to the point of this, a bind that other people can't see doesn't need any open ports, and one that other people do need to see should be as conformant and interoperable as possible with other nameservers; if people can't find your servers, your service is useless.

Your iptables is going to need something like the following in it...

-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT

How you add these is up to you. I maintain my iptables file manually, but many people prefer to use the iptables administration tool.

Configure bind9 as master/slave pair on CentOS / RHEL 5

There are plenty of HOWTO documents on this and I've discovered that nearly all of them are full of unnecessary fluff that can be both confusing and misleading. It's probably because they are reworks of older HOWTOs from the bind8 era. Configuring bind9 in master/slave is far easier and requires far fewer configuration changes than the existing HOWTOs suggest.

You need to edit the named.conf files on both systems. I'm assuming that you begin with a functioning but otherwise default configuration on both machines.

bind named records not updating properly

If DNS records are not updating properly, appear inconsistent or random but zone file looks fine...

This usually means that somewhere you forgot to update a serial for the domain and new zone info is not propagating to slave servers. The best long-term solution is to (at least) use a script to 'wrap' edits to your zone files. The script runs sed at the end to update the serial. Other solutions involve putting all your zone info in a database and then building zone files from the db "automatically". This means you can't create a corrupt zone file by accident (nasty), and you can run as many nameservers off the db as you like, making multiple nameserver maintenance a breeze.

Inspect bind named records using dig

dig can be used in various ways, here are a few common usage scenarios:

Basic query of A records, using default nameserver:

dig testdomain.com.

Check MX records:

dig testdomain.com. MX

Check MX records using a particular nameserver:

dig @ns1.foobar.net. testdomain.com. MX

Do reverse lookup:

dig -x 111.222.112.191

The default query class for dig is IN and you rarely need to change this. You can query any type of record (CNAME or TXT for example) in the same way that MX are queried in the example above.

You can do tests using a TSIG signature when testing master/slave configurations: Use -k to specify the key filename or -y to pass the key on the command line (though this is a security risk on a multi-user system) - using -k is probably easier anyway.

Network Services don't work

You've installed a package, configured it, started it up and it seems to be running fine, but nothing is happening.

Did you forget to add iptables rules for the ports used by your new service? Don't forget that bind9 uses UDP as well as TCP.

Edit /etc/sysconfig/iptables and add rules to open up the necessary ports. You can also use iptables -e commands, but this stops you putting useful comments in your iptables file because iptables gets auto-generated. OTOH, don't hand edit iptables unless you are confident you aren't going to save a broken one and lock yourself out of the system. Never run system-config-securitylevel unless you want to trash your hand-edited iptables file.

Don't forget to 'service iptables restart' after making updates to the file.

Use 'netstat' to debug ports and service issues. For example, netstat -l -t -u -p -e will give a nice display of listening tcp and udp ports. Add --numeric-ports to see port numbers instead of names. The man page for netstat is fairly comprehensible, unlike some.

CentOS 6 start network connection on boot

Unlike CentOS 5, CentOS 6 desktop install does not configure network devices to start on boot.
Assuming that your main wired connection is eth0...

Edit /etc/sysconfig/network-scripts/ifcfg-eth0 and change the lines

NM_CONTROLLED=”yes”
ONBOOT=”no”

to

NM_CONTROLLED=”no”
ONBOOT=”yes”

The same principle applies to other network devices.
If you make other changes to these files besides the start behaviour, run service network restart so it can take effect.

Configuring a VPN tunnel from Fritzbox 7390 to Juniper SSG5

Many people seem to be following the guides on how to set up infrastructure VPN using Fritzbox and still can't get it to connect. If the Fritzbox logs anything at all about the problem it's just a cryptic error number. You can look the numbers up easily enough, but the short phrase "timeout" or "bad hash" doesn't do much to narrow down the problem.

The real cause of mysterious 0x2020 and 0x2027 errors and connection failure

If you're prepared to struggle with the numerous German language postings on the 7390 you'll find that while many posters insist that the recipe for VPN success is simple, others can't seem to make it work no matter what they try.

When you copy all the instructions verbatim, then try everything else as well, and all you get is <nothing> in the Fritzbox log, or a bunch of cryptic 0x2020 or 0x2027 errors, the problem is almost certainly related to MTU. While this ought to be fairly easy to work out, I haven't found a single post on the topic that mentions MTU even once. If you have tried everything with your Friztbox, then MTU is probably the problem - it seems sensitive to MTU when other boxes get by just fine with a default value.

The Juniper SSG5 allows you to dump the entire packet trace of an attempted IPsec negotiation, revealing that the Fritzbox sends some questionable messages regardless of configuration, and these will result in 0x2027 errors, but they don't stop it eventually connecting. However, the 0x2020 errors indicate a fatal problem, almost certainly related to MTU settings.

But the Fritzbox won't let me set the MTU!

The interface and options on the manufacturer's standard shipped interface to the 7390 are limited indeed. It wasn't until a recent update that we got the ability to set-up a VPN without recourse to a laughably poor tool from AVM that only ran on windows, despite the fact that it could have been knocked up in a few dozen lines of python or ruby.

AVM themselves say:

The FRITZ!Box does not allow you to adjust the MTU size manually. This is also not necessary because the FRITZ!Box supports the MSS clamping procedure (Maximum Segment Size) that automatically adjusts the size of data packets being sent to a connected network with a smaller MTU. Hence there will not be any performance losses due to fragmented or discarded data packets.

This is all very well, but it's quite clear that the Fritzbox cannot reliably detect LAN routes and adjust MTU accordingly so that tunnel packets don't become mangled.

Short of opening up your 7390 with modified firmware using Freetz you cannot get around a genuine MTU issue on the Fritzbox, and if the other end of your tunnel is another Fritzbox, then you are genuinely out of luck. However, most people with VPN problems are trying to connect to somewhat more transparent hardware, such as Netgear ProSafe, Draytek Vigor or perhaps a Juniper SSG5 - just about every other manufacturer out there allows MTU adjustment, even cheap TP-Link boxes allow it. The inability to set MTU for VPN tunnels is a serious oversight.

Setting the MTU on a Billion, Belkin, Netgear or Draytek is simplicity itself, but configuring VPN tunnels on the Juniper SSG involves an understanding of a wide range of options and complex choices, so many may be in need of some help in that regard.

The Fritzbox Side

First create your Fritzbox configuration file

Don't bother with the utility program. All you need is a simple text file in ANSI/OEM format. I'm actually somewhat uncertain exactly what encoding is required, though reports suggest that UTF8 does not play well with the parser. In any event, you won't need to input any strange character codes unless you are trying to use a FQDN with fancy characters in it and I'm not even going to talk about using a domain name or dynamic DNS here.

It's said that you should edit your VPN configuration file in DOS mode (with CR+LF line endings). Whether this is absolutely necessary I'm not sure, but DOS mode files do work, so you should probably stick to that, and if using a Linux based editor, it would be best to set it to use CR+LF endings. The Fritzbox saves out its main configuration file backups in Linux format (LF line-endings), but AVM's VPN utility saves out DOS format files and I've never tried loading Linux line endings into the VPN setup.

Your configuration file should look something like the following

vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "ddd.ddd.ddd.ddd";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = ddd.ddd.ddd.ddd;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = rrr.rrr.rrr.rrr;
                localid {
                        ipaddr = fff.fff.fff.fff;
                }
                remoteid {
                        ipaddr = ddd.ddd.ddd.ddd;
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "yoursharedsecret";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = fff.fff.fff.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = rrr.rrr.rrr.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any rrr.rrr.rrr.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF

Unfortunately, AVM don't make much effort to document their configuration file format, options or behaviour, instead expecting users to rely on a fairly inadequate Windows utility and highly inadequate built-in configuration tools. While the Fritzbox has a great feature-set on paper, the restrictive firmware often lets users down, and in the case of VPN it can cost a lot of time and effort to get a working configuration. Using information from the German forums and experimentation, I'm taking a best guess at how the options function.

The pre-shared key must match the value you put in the other end of the tunnel exactly. Make sure you don't have any invisible characters hiding on the end and it isn't longer than 49 characters (or shorter than 8). The Fritzbox will allow a short string here, but other boxes may not, or may even impose a fixed length (which substantially reduces the key-space, but does prevent easily guessable keys).

Do not confuse the "reject_not_encrypted = no" setting with somehow enabling unencrypted transmission, that's not what it does - if set to 'yes' it would force the local network specified in the tunnel definition to use only the tunnel route - which would force all external traffic through the tunnel. If that's what you want to happen, set it to yes.

You may have noticed the line "mode = phase1_mode_aggressive;"... Some sources will suggest that you use main mode for a pair of static IPs. This is good advice in general, but I have not had any success at all the 7390 negotiating a link with the SSG in main mode, despite having two fixed IPs. You can try setting "mode = phase1_mode_idp;" and setting your other end accordingly. If you're using a different version of ScreenOS to me, or have a different box entirely, perhaps it will work.

You may also wonder that I've chosen to turn off NAT traversal. While this option does work, and you can use it if you really need it, try without it first. Sometimes turning this off can get rid of annoying timeouts during negotiation, even if the negotiation is eventually succeeding.

"editable = no" prevents editing this configuration in the new Fritzbox GUI. It would probably only mess it up as it's only intended to handle a very narrow range of configurations.

The values chosen for the phase1 and phase2 configurations are almost the vanilla values set by the AVM program. You can try playing about with these, but I wouldn't bother. The Freetz people are saying that the list of supported strings has been substantially reduced under 6.20+ versions of the firmware. A value you might actually want to try out is "dh5/aes/sha" as this is a reasonable combination of DH group and AES, but there doesn't appear to be a phase2 equivalent, and all phase 2 configurations seem to be group 1 or 2.

Navigate the Fritz web interface to Internet >> Permit Access >> VPN and hit the "Add VPN Connection" button. If you have a choice, choose to upload an existing configuration file (Import a VPN configuration from an existing VPN settings file). Hit "Choose File" then locate the file on your local machine and OK it. Wait, wait, wait. After a while the file name will pop up next to the Choose File button. Once it shows up you can hit OK to perform the upload. The Fritzbox will show you a blue busy bar for a while ... or if you messed up the configuration file completely you'll see a red bar and a failure message.

On the VPN page ensure that the tunnel is enabled and then move on to the other end...

Configuring a Fritz 7390 compatible tunnel on the Juniper SSG5

I'm going to discuss how to create a route based tunnel here. Some examples show policy based tunnels, but you must have a concrete tunnel interface to control MTU, and any policy based tunnel that uses a tunnel interface binding is complex; you probably don't need that sort of set-up. On the other hand, a policy-based tunnel is very easy to set up if you want the most basic kind of tunnel using a tunnel action, but it won't cut it in this case.

In the examples below, ethernet0/0 (trust-vr) is connected to the internet - and it's the physical interface I am going to run the tunnel through. If you have configured your SSG differently, then substitute your local value for ethernet0/0 (trust-vr) accordingly.

Create the Tunnel Interface

This is done from Interfaces >> New [Tunnel IF].

Create the Tunnel Interface on the SSG

The example above uses tunnel.3, but yours is unlikely to be the same. The interface will offer the first unused tunnel. Just make sure you refer to the same tunnel you create here, later, when binding the VPN.

You need to create an explicit tunnel interface so you can set the MTU on it, and you can see that I've set it to 1300 here, which is about as small as you would ever need to go. Depending on the nature of your problem, a larger setting might work. If 1500 (or 0) works then you don't have an MTU problem :)

It's a useful short-cut to put the interface in the untrust zone. Complex scenarios using a custom zone also work, but if you're happy doing that you don't need this guide. Do not put the interface in the trust zone; this doesn't work well at all and may result in a one way tunnel regardless of the policies you set, or not work at all, depending on how your trust zone and other (real) interfaces are set up - due to a requirement for non-obvious routes and policies.

Create the Phase 1 Proposal Type

The SSG doesn't have the Phase 1 AES256 + SHA-1 pre-shared option that the Fritzbox offers first, so we need to create it.

Create the phase 1 proposal on the SSG

You'll need to select this proposal in the gateway advanced settings later.

Create the Gateway

The basic gateway settings are something like this; these are the defaults in fact. All you have to do is fill in the external IP address of the Fritzbox.

Create the gateway on the SSG

Modify the Gateway Advanced Settings

Unlike the basic settings, there is a bit more to change here. Fill out the pre-shared key to whatever value you're using and set the phase 1 proposal to use the value you created previously.

Don't tick NAT Traversal until you've determined that you really need it. If you do set it, it must match the value in the Fritzbox configuration file.

Note that you don't have to set this just because you have NAT on your local network; it's nothing to do with that. This is mainly useful to work around NATs you can't see, such as stealth NAT or blackhole routing by ISPs or co-location providers. Setting this value restricts UDP communications to a single port. In theory it should be more dependable, but it also adds some overhead. I've found it isn't always necessary, even if there is a NAT in play. In practice, such NATs may forward the UDP traffic you need anyway; your mileage may vary.

Set the gateway advanced settings on the SSG

The pre-shared key value can be anything as long as it matches the value you put in your Fritzbox configuration file, but a random string of characters would probably be best. 49 characters is usually the upper limit in length.

Create the VPN

The menu option is actually called AutoKey IKE because it's distinct from manual keying.

Create the AutoKey IKE VPN on the SSG

All you have to do here is pick the gateway you created previously and then move on to the 'advanced' settings.

VPN Advanced Settings

After picking the gateway, click the 'Advanced' button to set up the important stuff.

Continue to create the AutoKey IKE VPN on the SSG

Set up the phase 2 proposal. You only need one value, this will be the first thing the Fritzbox suggests.

Set up the address mapping. As with the example Fritzbox settings, these may vary for your local net. Here 10.1.1.0/24 is the local address range on the SSG bgroup1 and 192.168.10.1/24 is the address range on the Fritzbox.

Select the tunnel binding and select the tunnel interface you made at the start. Make sure this is the correct tunnel interface. The example uses tunnel.3 but your tunnel may have a different number - make sure it's the one you created earlier.

Turn on VPN Monitor, Optimized and Rekey. If you try to use monitor without optimized, it probably won't work. Monitor causes the SSG to use ICMP packets to monitor the connection status to the other end of the tunnel.

Choose a 'Destination IP' for VPN Monitor that will always be there and able to respond to ping, such as the Fritzbox itself. The IP is a local IP, so 192.168.10.1 would be the obvious value in this example. If you don't fill it in the SSG will guess.

Rekey causes periodic reconnection, regardless of tunnel use. If you don't set it, your tunnel will drop when there is no traffic over it. This can be a problem because it then has to renegotiate to bring the tunnel up on demand, which takes a long time and can cause timeouts, so you most likely want it set.

Create the tunnel Route

Because this is a route-based tunnel, it won't work without a route to direct traffic into it.

We will be using a regular destination based route. The destination in this case is the local IP range on the Fritzbox, which is 192.168.10.0/24 in our example (fff.fff.fff.0 from our Fritzbox configuration file). We want to route this destination through our tunnel (in the example, tunnel.3).

Set up the tunnel route on the SSG

Select Network >> Routing >> Destination and fill out the destination address range, then select 'Gateway' and pick the required tunnel interface; yours may be a different tunnel number, make sure it's the one you bound to in the previous step. You should be using the same tunnel interface you created in the very first step.

You don't need a reverse route; you should already have a suitable route. If you could already route to your local interface (in the case of the example bgroup1) then your tunnel packets will also be routed there. As long as you put this route in the correct virtual router it will work. I've put everything in trust-vr for this example, as that is the most obvious use case.

Create the tunnel Policy

This isn't a policy based tunnel, so a policy may not be needed. If you have the default trust -> untrust ANY policy, then that will cover it for outgoing packets. You do not need a tunnel policy, and you would not be allowed to add one anyway because the tunnel is already bound.

You probably need a policy for incoming packets, such as the one shown below.

Set up the tunnel route on the SSG

I would normally use a pre-defined address range set up in Policy Elements >> Addresses here instead of simply putting in the address range directly, but it's clearer as an example this way (and avoids some steps that are really nothing to do with VPN setup).

Note that there is no tunnel setting here, it should be a regular policy with PERMIT as its action.

Supported Fritzbox Configurations

Phase 1

According to the Freetz postings, the following are the only supported combinations for phase1ss

  • dh5/aes/sha
  • dh14/aes/sha
  • dh15/aes/sha
  • def/all/all
  • alt/all/all
  • all/all/all
  • LT8h/all/all/all

Phase 2

And these are the only supported phase2ss combinations.

"pfs" relates to "Perfect Forward Security", which reduces your vulnerability to initial key compromise attacks. The SSG5 supports this, so you can turn it on - this is done simply by not selecting a Phase 2 proposal option with nopfs - if it doesn't say nopfs, pfs is assumed.

The cryptic LT8h appears to refer to live-time-8 hours. People have reported issues with this so I didn't try it.

  • esp-3des-sha/ah-no/comp-no/pfs
  • esp-3des-sha/ah-no/comp-no/no-pfs
  • esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs
  • esp-aes-sha/ah-all/comp-lzjh-no/pfs
  • esp-all-all/ah-all/comp-all/pfs
  • esp-all-all/ah-all/comp-all/no-pfs
  • esp-all-all/ah-none/comp-all/pfs
  • esp-all-all/ah-none/comp-all/no-pfs
  • LT8h/esp-all-all/ah-none/comp-all/pfs
  • LT8h/esp-all-all/ah-none/comp-all/no-pfs

OpenSSL Certificate Creation Basics

How to create certificates with OpenSSL

First, create an RSA private key:

openssl genrsa -out ca.key 1024

The key above won't be encrypted. Often you won't want an encrypted key, instead you'll want to put it somewhere safe, where only root can read it. Alternatively, if you wan to encrypt the key, use the version below.
openssl -des3 -out ca.key 1024

If you're hoping for your encryption to be secure, then forget des3 and use aes256...
openssl -aes256 -out ca.key 2048

The default key-length is 512, in the first two examples we specify 1024. Lately, 2048 is more appropriate if you're hoping for security that's hard to break.

Then, generate a certificate signing request using your new key:

openssl req -new -key ca.key -out ca.csr

You will be prompted for information.

Then, you can either send your .csr off to a certificate authority for them to sign properly, or you can self-sign the key:

openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt

The self-signed certificate can be used directly in most *nix applications. However, for Windows it's not a good approach, but if you're making keys under windows, you use makecert not openssl.

If you want to install a certificate as a genuine Certificate Authority (CA) and use it to sign other certificates, you'll need to generate a Certificate Revocation List (CRL) as well. Then you can distribute the CA and CRL, and all the keys signed with the CA will work where you have the CA and CRL installed. This is a useful approach when you want to generate a lot of keys and use them for individual user authentication, such as SSH logins. In this case you do not distribute the key; you keep the key locked up safe and encrypted; it's not needed for signature validation, only the CA and CRL.

What FTP daemon to use with CentOS or RHEL 5.X

What ftp daemon to use on CentOS or RHEL? I recommend vsftpd - you can install it through yum and it's very secure.

The set-up info on the vsftpd site could be better though. In particular, there is no explanation of how vsftpd uses pam to authenticate.

Look in /etc/pam.d/vsftpd and /etc/pam/ftp or whatever you've set in the pam_service_name option e.g. ftp=/etc/pam/ftp to see how pam is set up for this service.

After editing passwords for vsftpd use something like db_load -T -t hash -f accounts.tmp accounts.db

Where you have your users and passwords in accounts.tmp, with usernames and passwords on alternate lines. You might find some contradictory instructions about on the net, but they won't work for CentOS 5.X

Apple wired USB keyboard with numeric pad - working drivers for Windows 7 on an ordinary PC

Overview of the Apple Ultra-thin USB Keyboard Problem

I have a full-width Apple keyboard of the newer flat aluminium type (Ultra–thin USB) that I use with a regular PC and a Mac via a KVM. It works with Windows without any special drivers - to some extent - but unless you do something you won't have any ability to type Print Screen, Scroll Lock, Pause/Break or Insert keys.

When I looked on the internet to see whether there was a proper PC driver file for it, I found a lot of outdated, confusing, contradictory and muddled information. Some references are to very old versions of OSX or Boot Camp Tools, others to older versions of Windows or the keyboard itself.

I decided to write down what I had to do to make this keyboard work 'as intended' with Windows 7 from an up to date copy of Boot Camp Tools for OSX 10.6 Snow Leopard or 10.7 Lion.

I don't know if these instructions will help you with a wireless keyboard as I don't have one to try, but at least the information about Boot Camp Tools is up to date.

This is the device I'm talking about on Amazon.

Your options are:

The Apple keyboard maps a few keys strangely: there is no Insert key, and Print Screen, Scroll Lock, and Pause/Break are not labelled. Also, Num Lock is labelled 'Clear'. Apple have their own pages on this topic, but surprisingly, they are partially incorrect.

Apple's own descriptions of how to type Print Screen, Scroll Lock, and Pause/Break are wrong - in fact these keys are activated in the following way:

I suspect they have confused the key presses required for these with the presses you must make on the compact wireless keyboard, which has no F13 .. F19 keys.

Why they didn't assign these to F13, F14 and F15 so they align to the three function-key grouping above Fn, Home and PageUp, as would normally occur on a PC keyboard is beyond me as F13 isn't assigned to anything special.

How to install Apple's own Windows drivers for the wired Apple keyboard

You need a copy of Apple's Boot Camp Tools to do this.

You can download the latest Boot Camp Tools via the Boot Camp Assistant in OSX: run Boot Camp Assistant and select the option to download the latest support tools. Once the download is complete it will help you write them to a CD, DVD or external drive.

Apple don't publish a link to download Boot Camp Tools or the keyboard driver directly on their support site I find this irksome, but Apple don't seem to want PC users who didn't buy a Mac using their keyboard drivers; it's the only conclusion I can draw from Apple's decision to make the drivers only downloadable via an OSX utility; they could easily have submitted the keyboard drivers to Microsoft so that they were distributed with Windows 7, or put them on their own site, or on a CD, or made them freely distributable but they do none of these things.

There are various Boot Camp Tools related downloads on their site, but none appear to be the actual disc image. (If you can find a link, please let me know). If you don't have an OSX install disc you may be able to locate a copy of the driver install file by other means - see below.

I made a CD of my Boot Camp Tools. I suggest you do likewise, as it's convenient when doing a Windows install, or when you want to put the keyboard drivers on a new PC. The Boot Camp assistant will ask if you want to burn a discs after you have downloaded them. With the Boot Camp Tools disc in your PC, navigate to the correct directory:

If you have OSX 10.6 and a 3.X version of Boot Camp Tools

If you have OSX 10.7 and a 4.X version of Boot Camp Tools

Some guides will tell you that you need to run the main Boot Camp Tools setup (setup.exe) or the main driver installer (BootCamp.msi or BootCamp64.msi) - do not do this! The advice is wrong and in any event it's no longer possible. Apple have added a check to the main tools setup and main driver .msi to ensure that you're running on genuine Mac hardware, and if you aren't, you can't install. It used to be possible to run, but it is no longer an option. Even when it was possible it was a bad idea, as it could result in long delays on start-up. The keyboard driver installer doesn't contain such a check, so installing it standalone is still possible but I wouldn't be surprised if a future version of the driver will only work on Apple hardare - it would be obstructive in the extreme, but in line with other things Apple have done so far.

Making the top row of keys default to acting as function keys

The downside to running the keyboard driver install without the rest of the Boot Camp Tools is that you need to edit the registry manually to change how function keys are handled. By default the driver sets the top row of keys to perform multimedia functions (most of which don't work anyway, despite their being legitimate windows key messagers for them, they produce special Apple codes instead); and so you have to press the Fn key to make the top row keys produce functions key codes. What most people want/need is for the keys to produce function key codes by default and the broken multimedia functions when you press Fn - as Windows and most PC applications tend to use the function keys for a lot of useful short-cuts. There is an option in the Boot Camp Tools applet to change this behaviour, but it's also possible to change it without the applet.

The way that the driver handles the top row of keys is controlled by a single registry entry, so it's not hard to change it so that you don't need to press Fn to have them act as function keys by default:

Once you have installed the keyboard driver, run regedit using Start Menu >> Run and then navigate to:
HKEYLOCALMACHINE\SYSTEM\ControlSet001\Services\KeyMagic\OSXFnBehavior

There will be a 'Binary' entry with the value 01
You need to set this to zero. Some people say you should change this to a DWORD entry, but that's not true. However, to cover all contingencies, I edited the value to 00 00 00 00 - which is four bytes of zero, equivalent to a DWORD 0. This is easier than changing the type of the value and has the exact same effect. As far as the registry access API is concerned, four bytes of 00 and a DWORD value of 0 are the same.

Whatever the driver is doing to read the entry, I found that setting OSXFnBehavior to 00 00 00 00 did the trick, and afterwards my function keys worked as function keys without having to press Fn. You may need plug and unplug the keyboard to make this work after editing - the driver doesn't seem to check this value continuously.

With this configuration, you still need to press Fn + Enter on the numeric pad to type an Insert. You can always use KeyTweak to map something else (such as F13) to Insert but you can't remap the Fn key as it does not produce a key code. As an aside, the location of the Fn key where Insert is normally found on a PC keyboard was a terrible one, it makes it very hard to use on a Mac or PC and it's probably the worst thing about this keyboard - especially when moving back and forth from a MacBook keyboard that puts Fn on the far left.

I found that the track-forward, play/pause and track-back multimedia keys work as expected in iTunes, but the mute/unmute and volume keys do not. Unsurprisingly, the other special functions don't do anything either. If you inspect the scan codes generated for these keys (which, apart from Eject you access via the Fn key once you have the registry change in effect), you'll see there aren't any, so they can't even be remapped in KeyTweak. The Exposé and Dashboard functions produce the standard F3 and F4 scan codes even if you press Fn so they don't do anything special either.

If you don't have a copy of Boot Camp Tools

Without any driver installed, the keyboard allows you to use the function keys normally, and 'Clear' still works as Num Lock, which is fine but there is no way to type Insert, Print Screen, Scroll Lock or Pause/Break.

If you don't have access to Boot Camp Tools, really the best thing to do is to use KeyTweak. It doesn't install any services or anything that has to run at startup. In fact the only time it consumes resources is when you are running it explicitly to edit your settings. This is because it relies on functionality already built into Windows. It's merely a nice way of creating/editing a registry entry that already exists in Windows to support remapping of scan codes for non-standard keyboards.

The only downside of this is that it doesn't play well if you swap keyboards around because you may not want those alternate mappings applied to your other keyboards. If you don't use the Apple keyboard all the time, you may want to make registry scripts to turn the scan code remappings on and off.

An alternative is to somehow obtain a copy of the Apple driver. Apple go out of their way not to distribute it; they also explicitly prohibit redistribution in their license terms for Boot Camp Tools! So, I'm not going to upload a copy here.

However, a search for AppleKeyboardInstaller.exe soon turns up lots of people who don't seem to care about their license terms :) and have uploaded the file.
Of course, some of these may have been tampered with to contain malware, or may simply be very old versions that don't support Windows 7, or may do something else strange, so I've put the MD5 hashes for the most recent versions (at the time of writing) below so you can at least check anything you download.

Apple Keyboard Installer MD5 Hashes

Driver file name Boot Camp Tools Version   OS Version   MD5 Hash
AppleKeyboardInstaller.exe 3.2.2856 OSX 10.6 E5AE11C2AA0D9BCAF4A99EC55D0BD415
AppleKeyboardInstaller64.exe   3.2.2856 OSX 10.6 B4CDD38C5FC180A12C88371311039E8D
AppleKeyboardInstaller.exe 4.0.0.1 OSX 10.7 F0015AA3A67655A31417985B849E93D2
AppleKeyboardInstaller64.exe 4.0.0.1 OSX 10.7 5E41048519F031814E3FEF0B4948E80B