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.
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.
Simply pinging one gateway from the other is not useful. Such a ping does not normally go through the tunnel. The tunnel handles trafiic between the two protected subnets, not between the gateways. Depending on the routing in place, a ping might
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 as some other Unix versions do, according to mailing list comments. However traceroute as described above does work.