Linux FreeS/WAN Troubleshooting

This is mainly a placeholder for an as yet unwritten document. Some brief notes:

Problem Reporting

For how to report problems, see the file doc/prob.report.

Test with ipsec manual before going to auto

Manually keyed connections do not require key negotiation between Pluto and the key daemon on the other end.

If a manually keyed connection works and auto doesn't, suspect one of:

If auto connections sometimes work but sometimes fail mysteriously, check for: If manually keyed connections don't work, suspect one of:

Information available on your system

ipsec.conf(5)
Manual page for IPSEC configuration file.
ipsec(8)
Primary man page for ipsec utilities.
Other man pages
are on this list and in
/proc/net/ipsec*
Various files reporting the status of IPSEC.
ipsec look
Brief status info.
ipsec barf
Copious debugging info.

ifconfig reports for KLIPS debugging

From a mail message from our KLIPS developer:
Here is a catalogue of the types of errors that can occur for which
statistics are kept when transmitting and receiving packets via klips.
I notice that they are not necessarily logged in the right counter.
. . .

Sources of ifconfig statistics for ipsec devices

rx-errors:
- packet handed to ipsec_rcv that is not an ipsec packet.
- ipsec packet with payload length not modulo 4.
- ipsec packet with bad authenticator length.
- incoming packet with no SA.
- replayed packet.
- incoming authentication failed.
- got esp packet with length not modulo 8.

tx_dropped:
- cannot process ip_options.
- packet ttl expired.
- packet with no eroute.
- eroute with no SA.
- cannot allocate sk_buff.
- cannot allocate kernel memory.
- sk_buff internal error.


The standard counters are:

struct enet_statistics
{
	int	rx_packets;		/* total packets received */
	int	tx_packets;		/* total packets transmitted */
	int	rx_errors;		/* bad packets received */
	int	tx_errors;		/* packet transmit problems */
	int	rx_dropped;		/* no space in linux buffers */
	int	tx_dropped;		/* no space available in linux */
	int	multicast;		/* multicast packets received */
	int	collisions;

	/* detailed rx_errors: */
	int	rx_length_errors;
	int	rx_over_errors;		/* receiver ring buff overflow */
	int	rx_crc_errors;		/* recved pkt with crc error */
	int	rx_frame_errors;	/* recv'd frame alignment error */
	int	rx_fifo_errors;		/* recv'r fifo overrun */
	int	rx_missed_errors;	/* receiver missed packet */

	/* detailed tx_errors */
	int	tx_aborted_errors;
	int	tx_carrier_errors;
	int	tx_fifo_errors;
	int	tx_heartbeat_errors;
	int	tx_window_errors;
};

of which I think only the first 6 are useful.

Testing Between Gateways

Sometimes you need to test the tunnel between two security gateways. This can be done by having a machine behind one gateway ping a machine behind the other gateway, but this is not always convenient or even possible.

Simply pinging one gateway from the other is not useful. Such a ping does not normally go through the tunnel; the tunnel is between the subnets, not between the gateways. Depending on the routing in place, a ping might succeed by finding an unencrypted route or fail by finding no route. Neither event tells you anything about the tunnel. You can explicitly create an eroute to force such packets through the tunnel, but that is an unnecessary complication.

The trick is to explicitly use an IP address for the subnet-side interface of one gateway machine, either as the target of a ping or as the origin of a traceroute. Since that interface is on the protected subnet, the resulting packets do go via the tunnel.

From the mailing list:

> >I have two gateways, SG1 and SG2, with I/Fs i and e (for internal and
> >external), and two hosts, H1 and H2 set up as:
> >
> >     H1-----(i)SG1(e)===========(e)SG2(i)------H2
> >
> >And I want to test a tunnel set up between the H1 subnet and the H2
> >subnet, but the H2 host may not exist yet, or may not be responding.
> >
> >If I ping SG2i from H1, all traffic in both directions is encrypted,
> >testing the tunnel.
.....
> >If I understand correctly, this could be accomplished by the 'ping -I'
> >feature of which you spoke earlier or 'traceroute -i'?
> 
> Indeed, 
>   traceroute -i eth0 -f 20 otherSG 
> appears to give me a solution using only N machines, the SGs themselves.
> This is very nice.  Note that in this example, eth0 is the *private* (i)
> interface.  If you try it with the (e) interface or the ipsec0 interface,
> you won't get the desired result.  If you leave off the -f 20, the trace
> will hang in some totally bizarre way.
Linux does not seem to support ping -I correctly, according to mailing list comments, but traceroute as described above does work.
Click below to go to: