If a manually keyed connection works and auto doesn't, suspect
one of:
In our current implementation, only the original initiator can
initiate re-keying. If the responder has a shorter SA lifetime,
then when that lifetime expires, responder takes down the connection.
Responder, however, cannot build a replacement connection and the
initiator does not since his lifetime hasn't expired.
Linux FreeS/WAN does include
DES
since it is a
mandatory part of the IPSEC
standard but our default configuration disables it
because DES is insecure. Some
implementations may offer DES as the default. In such cases
we urge you to change them to
Triple DES. This is our
default.
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:
If auto connections sometimes work but sometimes fail mysteriously,
check for:
If manually keyed connections don't work, suspect one of:
e.g. incorrect interface or next hop information
Information available on your system
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.
> >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: