DES is a mandatory part of the IPSEC standard. Despite that, we will not implement DES. We believe it is more important to provide security than to comply with a standard which has been subverted into allowing weak algorithms.
Some implementations may offer DES as the default. In such cases we urge you to change them to Triple DES. If this is not possible, for example because export laws prevent your vendor from offerring you adequate crytography, we urge you to complain vigorously to your government, the vendor, and the embassy of the nation whose laws are problematic for you. In the meanwhile, use FreeS/WAN to get strong crypto until the laws are fixed.
FreeS/WAN does have DES code in it as a sort of historical accident, since we need it to implement our default (currently, our only) block cipher, Triple DES. However, since DES is insecure, we do not provide any interface to that code and, as a matter of policy, will provide no help to anyone who may wish to use it.
Until ipsec auto and whack/pluto get fixed: When puzzled by Pluto behaviour, always look in /var/log/secure -- that's the unadulterated story. To get the whole whack output (almost a subset of the story from Pluto), give auto the --verbose flag on each invocation. Eg: ipsec auto --verbose --up sadaisy Bonus hint: problems snowball. So look for the first problem first, it is likely to be the cause of later problems. And a final hint: If one side keeps retrying to no avail, it may be because the other is unhappy about something and won't reply. Go look at the other side to figure out what it doesn't like.
Background: When one IKE system (for example, Pluto) is negotiating with another to create an SA, the Initiator proposes a bunch of choices and the Responder replies with one that it has selected. The structure of the choices is fairly complicated. An SA payload contains a list of lists of "Proposals". The outer list is a set of choices: the selection must be from one element of this list. Each of these elements is a list of Proposals. A selection must be made from each of the elements of the inner list. In other words, *all* of them apply (that is how, for example, both AH and ESP can apply at once). Within each of these Proposals is a list of Transforms. For each Proposal selected, one Transform must be selected (in other words, each Proposal provides a choice of Transforms). Each Transform is made up of a list of Attributes describing, well, attributes. Such as lifetime of the SA. Such as algorithm to be used. All the Attributes apply to a Transform. You will have noticed a pattern here: layers alternate between being disjunctions ("or") and conjunctions ("and"). For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is cut back. There must be exactly one Proposal. So this degenerates to a list of Transforms, one of which must be chosen. In your case, no proposal was considered acceptable to Pluto (the Responder). So negotiation ceased. Pluto logs the reason it rejects each Transform. So look back in the log to see what is going wrong.
| Jan 17 16:21:10 remus Pluto[13631]: "jumble" #1: responding to Main Mode from Road Warrior 130.205.82.46 | Jan 17 16:21:11 remus Pluto[13631]: "jumble" #1: no suitable connection for peer @banshee.wittsend.com | | The connection "jumble" has nothing to do with the incoming | connection requests, which were meant for the connection "banshee". You are right. The message tells you which Connection Pluto is currently using, which need not be the right one. It need not be the right one now for the negotiation to eventually succeed! This is described in ipsec_pluto(8) in the section "Road Warrior Support". There are two times when Pluto will consider switching Connections for a state object. Both are in response to receiving ID payloads (one in Phase 1 / Main Mode and one in Phase 2 / Quick Mode). The second is not unique to Road Warriors. In fact, neither is the first any more (two connections for the same pair of hosts could differ in Phase 1 ID payload; probably nobody else has tried this).
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.
1) The log message some IKE message we sent has been rejected with ECONNREFUSED (kernel supplied no details) is much more suitable than the previous version. Thanks. 2) Minor suggestion for further improvement: it might be worth mentioning that the command tcpdump -i eth1 icmp[0] != 8 and icmp[0] != 0 is useful for tracking down the details in question. We shouldn't expect all IPsec users to figure that out on their own. The log message might even provide a hint as to where to look in the docs.Reply From Pluto developer Hugh Redelmeier
Good idea. I've added a bit pluto(8)'s BUGS section along these lines. I didn't have the heart to lengthen this message.