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.