Questions and Answers

Amy Rich

Thanks to Darren Dunham for pointing out an omission in the May issue. When discussing how to set up Solaris for printing to an HP printer, I neglected to mention that Solaris 8 doesn't actually ship with a bootpd. You can use the one available from HP in the jetdirect package. Other operating systems that come with their own bootpd can be configured without additional software, though. You can also use the dhcpd that comes with Solaris, but the required configuration steps are different.

Q At work we have a SonicWall VPN, and a number of home users have SonicWall's VPN client installed on their home PCs and working fine. We also have a cablemodem user with one dynamic IP that needs to access the network. Instead of having his PC hooked up to the cablemodem directly, he has a Solaris 8 machine acting as a gateway for his RFC1918 LAN. He only wants to use the VPN client on one of his PCs, though. The Solaris box is using ipfilter to do packet filtering and one to many NAT for various types of hardware on his LAN. Unfortunately, since he's doing NAT, he can't get his PC to talk to our VPN box. I took a look at the ipfilter package and the mailing list and FAQ, but there doesn't seem to be any clear-cut advice on how to set this up, if it's even possible. Do you have any pointers on how we could get this user connected to our VPN?

A The SonicWall VPN uses IPSec to create the connection between your office and your home users. Some background information about IPSec will probably help you understand the solution to the NAT issue. For some basic definitions, I'll quote from the IPSec RFC (http://www.faqs.org/rfcs/rfc2401.html). Other RFCs that you may want to take a close look at include:

AH: RFC2402 -- http://www.faqs.org/rfcs/rfc2402.html,

ESP: RFC2406 -- http://www.faqs.org/rfcs/rfc2406.html, and

ISAKMP key-exchange -- http://www.faqs.org/rfcs/rfc2408.html.

IPSec is designed to provide interoperable, high-quality, cryptographically based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic-flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper-layer protocols.

These objectives are met through the use of two traffic security protocols -- the Authentication Header (AH) and the Encapsulating Security Payload (ESP) -- and through the use of cryptographic key management procedures and protocols.

• The IP Authentication Header (AH) provides connectionless integrity, data origin authentication, and an optional anti-replay service.
• The Encapsulating Security Payload (ESP) protocol may provide confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. (One or the other set of these security services must be applied whenever ESP is invoked.)
• Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols.

A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher-layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher-layer protocols. In the case of ESP, a transport-mode SA provides security services only for these higher-layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification.

A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus an SA between two security gateways is always a tunnel mode SA, as is an SA between a host and a security gateway.

For a tunnel mode SA, there is an "outer" IP header that specifies the IPSec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header.

The SonicWall VPNs can be configured using either AH or ESP. What the above discussion of AH and ESP boils down to is that, if the SonicWall is configured to use AH, your user cannot access it through a one to many NAT (IP masquerading). AH specifies a cryptographic checksum across portions of the IP header, including the IP addresses. IP masquerading modifies the source IP address for outbound packets and the destination IP address for inbound packets. Since your user's Solaris box can't participate in the encryption key exchange, it can't generate the correct cryptographic checksums for the modified IP headers. The modified IP packets traveling through your user's Solaris gateway will be discarded by the SonicWall as invalid, because they fail the cryptographic checksum test.

The above quoted material from RFC2401 also states that you're going to need to use tunneling mode because the user's Solaris gateway is not an endpoint (the PC with the SonicWall client software on it), but a security gateway. So, the first step in making sure that your connection is going to work with your NAT user is to make sure that you have your SonicWall configured to do tunneled ESP. The following illustrates an example packet (from RFC2406):

Before applying ESP to an IPv4 packet:

-----------------------------------------
|             | ext hdrs   |     |      |
| orig IP hdr | if present | TCP | Data |
-----------------------------------------

---------------------------------------------------------------------
|  new IP hdr*  |     | orig IP hdr*  |     |      |   ESP   | ESP  |
| (any options) | ESP | (any options) | TCP | Data | Trailer | Auth |
---------------------------------------------------------------------
                      |<------------ encrypted ------------->|
                |<-------------- authenticated ------------->|

Now, on the user's end, ipfilter is going to have to pass packets for the ESP protocol and for the ISAKMP key exchange. ESP is protocol number 50 and the user should have it already listed in /etc/protocols on the Solaris 8 machine. ISAKMP is UDP protocol number 500, but it's not generally listed in /etc/services by default under Solaris. Your user can either add it to /etc/services or he can use the number instead of the name in his ipfilter configuration file. I'm going to assume that your user employs a fairly restrictive set of filter rules, so he'll need to implicitly allow everything that he wants to pass through.

The following rules should work, as long as they appear before any rules that explicitly block the mentioned ports using the quick option (so no more rule processing takes place). In this example, hme0 is the internal LAN interface of his Solaris box and hme1 is the external interface that's attached to the cablemodem. 10.1.1.1 would be the IP address of your SonicWall VPN, and 192.168.1.2 would be the IP address of his PC with the SonicWall client installed.

# Let the ISAKMP key exchange take place between the client and the VPN
pass out quick on hme1 proto udp from 192.168.1.2/32 port = 500 to 10.1.1.1/32 port = 500
pass in quick on hme0 proto udp from 192.168.1.2/32 port = 500 to10.1.1.1/32 port = 500
pass in quick on hme1 proto udp from 10.1.1.1/32 port = 500 to 192.168.1.2/32 port = 500
pass out quick on hme0 proto udp from 10.1.1.1/32 port = 500 to 192.168.1.2/32 port = 500

# Pass the encapsulated packets from the client to the VPN and back
pass in quick on hme1 proto esp from 10.1.1.1/32 to 192.168.1.2/32
pass out quick on hme0 proto esp from 10.1.1.1/32 to 192.168.1.2/32
pass out quick on hme1 proto esp from 192.168.1.2/32 to 10.1.1.1/32
pass in quick on hme0 proto esp from 192.168.1.2/32 to 10.1.1.1/32

A I believe that the IEEE has a complete list on their site: http://standards.ieee.org/regauth/oui/oui.txt

It looks like Cisco has 175 registered prefixes listed. If you have your machines hooked up to a managed switch, you should be able to see what MAC addresses are being transmitted over each port. Then you can see what's connected to that port. If you're using a central hub, though, you're going to have a tough time nailing down your offender.

Q I need to copy all incoming mail from our mail server to another mail server to test the new virus/filtering software on that machine before we put it into production. It doesn't matter whether or not the mail all goes to one user or many users on the new machine, but the mail must be delivered properly on the old machine. I'm running sendmail 8.12.2. What's the best way to do this?

A You have a few options. The size of your user base, load on your current machine, and how much effort you want to spend learning new software will probably help determine which of these is best for you. The obvious answer is to set up an alias for everyone in /etc/aliases that does a local delivery and also sends the mail to your new server. This is prohibitive if you have a larger user base, though.

Along the same lines, you can use procmail (http://www.procmail.org/) as the local delivery agent on your existing mail server, and modify the system procmailrc file have it forward a copy of every mail to an account on the new mail server.

If you don't want to go the way of aliasing, you can try the copyuser hack from Robert Harker in your sendmail mc file. Put the following in the cf/hack directory of your sendmail source code:

divert(0)dnl
VERSIONID('copyuser.m4')dnl
VERSIONID('Copyright 1998, Robert Harker, Harker Systems')dnl
VERSIONID('www.harker.com, info@harker.com, 408-295-6239')dnl
VERSIONID('Permission granted to use this as long as this')dnl
VERSIONID('VERSIONID information is preserved and')dnl
VERSIONID('it is not included in a commercial product ')dnl

ifdef('_MAILER_smtp_',,'errprint('*** MAILER(smtp) must appear before copymail mailer')')dnl

LOCAL_CONFIG
CPNOCOPY

LOCAL_NET_CONFIG
R$+<@$+.NOCOPY.> $#esmtp $@$2 $:$1<@$2.>
R$+<@$+.> $#copymail $@nohostneeded $:$1<@$2.NOCOPY>
R$+<@$+> $#copymail $@nohostneeded $:$1<@$2.NOCOPY>

MAILER_DEFINITIONS
# Copy a message by sending it back to sendmail with an additional address:
#       copyuser
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu,S=11/31,
R=ifdef('_ALL_MASQUERADE_', '21/31', '21'),A=sendmail  mailbackup $u

hack('copyuser')

The best but most complex solution (as far as learning curve goes) would be to compile sendmail with milter (http://www.milter.org/) support and use milter to copy mail over for each individual user. You'll also be able to capture outgoing mail as well as incoming if you use this solution. If you look in the sendmail src directory, there's an example milter listed in libmilter/README that will log all mail to a file. You could modify this for your purposes.

Q I've just inherited a Solaris 7 system that appears to be having some disk issues on /dev/rdsk/c0t0d0s0. The logs are showing bad blocks near the beginning of the partition. I've got a new disk on order, but I'm concerned that this machine is going to lose its super-block before the new disk gets here. In the event that this happens, I know that I can invoke fsck on an alternate super-block, but I need to know where that is. Is there any way to find out where the alternate super-blocks were stored when the filesystem was created? Are there any other file system parameters I should be concerned about?

A Though you can't, to my knowledge, actually reconstruct what the alternate super-blocks are from the existing disk, there's a good chance that you can make an educated guess. Unless someone specifically tweaked the settings when they ran newfs, you can have the system report the default options it would use when creating the slice:

newfs -N /dev/rdsk/c0t0d0s0

/dev/rdsk/c0t1d0s0:    2102400 sectors in 292 cylinders of 20 tracks, 360 sectors
       
1026.6MB in 23 cyl groups (13 c/g, 45.70MB/g, 11008 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 94000, 187968, 281936, 375904, 469872, 563840, 657808, 751776,
845744, 939712, 1033680, 1127648, 1221616, 1315584, 1409552, 1503520,
1597488, 1691456, 1785424, 1879392, 1973360, 2067328,

newfs -Nv /dev/rdsk/c0t0d0s0

mkfs -F ufs -o N /dev/rdsk/c0t1d0s0 2102400 360 20 8192 1024 32 6 120 4096 t 0 -1 8 128
/dev/rdsk/c0t1d0s0:     2102400 sectors in 292 cylinders of 20 tracks, 360 sectors
1026.6MB in 23 cyl groups (13 c/g, 45.70MB/g, 11008 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 94000, 187968, 281936, 375904, 469872, 563840, 657808, 751776,
845744, 939712, 1033680, 1127648, 1221616, 1315584, 1409552, 1503520,
1597488, 1691456, 1785424, 1879392, 1973360, 2067328,

Parameter (value as listed in above example, default value): Definition

sect (360, 32): The number of sectors per track on the disk.

ntrack (20, 16): The number of tracks per cylinder on the disk.

bsize (8192, 8192): Logical block size measured in bytes.

fragsize (1024, 1024): The smallest amount of disk space in bytes to allocate to a file. The value must be a power of 2 selected from the range 512 to the logical block size. If logical block size is 4096, legal values are 512, 1024, 2048, and 4096; if logical block size is 8192, 8192 is also a legal value.

cgsize (32, 16): The number of cylinders per cylinder group. The per-cylinder-group meta data must fit in a space no larger that that available in one logical filesystem block. If too large a cgsize is requested, it is decreased by the minimum amount necessary.

free (6, 10): The minimum percentage of free space to maintain in the file system. This space is off-limits to normal users. Once the file system is filled to this threshold, only the superuser can continue writing to the file system. This parameter can be subsequently changed using the tunefs command.

rps (120, 60): The rotational speed of the disk, measured in revolutions per second.

nbpi (4096, 2048): The number of bytes per inode, which specifies the density of inodes in the file system. The number is divided into the total size of the file system to determine the fixed number of inodes to create. It should reflect the expected average size of files in the file system. If fewer inodes are desired, a larger number should be used; to create more inodes, a smaller number should be given.

opt (s, t): Space or time optimization preference; s specifies optimization for space; t specifies optimization for time. This parameter may be subsequently changed with the tunefs command.

apc (0, 0): The number of alternates per cylinder to reserve for bad block replacement (SCSI devices only).

gap (-1, disk-type dependent): Rotational delay. The expected time (in milliseconds) to service a transfer completion interrupt and initiate a new transfer on the same disk. The value is used to decide how much rotational spacing to place between successive blocks in a file. This parameter can be subsequently changed using the tunefs command.

nrpos (8, 8): The number of different rotational positions in which to divide a cylinder group.

maxcontig (128, 7): The maximum number of blocks, belonging to one file, that will be allocated contiguously before inserting a rotational delay. For a 4K file system, the default is 14; for an 8K file system it is 7. This parameter can be subsequently changed using the tunefs command. This parameter also controls clustering. Regardless of the value of gap, clustering is enabled only when maxcontig is greater than 1. Clustering allows higher I/O rates for sequential I/O and is described in the tunefs man page.

Amy Rich, president of the Boston-based Oceanwave Consulting, Inc. (http://www.oceanwave.com), has been a UNIX systems administrator for more than five years. She received a BSCS at Worcester Polytechnic Institute, and can be reached at: qna@oceanwave.com.