[Swan] Can you elaborate on this ?
Philippe Vouters
philippe.vouters at laposte.net
Thu Jan 24 21:45:11 EET 2013
Hi Elison,
Apparently with your iked.conf setup, you installed a fairly old Shrew
version I have no knowledge on and never tested.
I only can grant with the software and their respective versions I
document on my Web site, I do get the result I am looking for in the
hardware/software environment I used at the time I wrote my document. I
always try with my Web documents to be accurate and demonstrative enough
so that anyone running under the same environment gets the exact same
result.
I don't, because I really can't, grant anyone running under any other
condition he will get a satisfying result using what I provide.
In the hope, this clarifies your expectations.
.
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org
Le 24/01/2013 08:28, Elison Niven a écrit :
> Hi,
>
> I can test with the Shrewsoft client in the fedora repos.
> I do not know how to configure local and remote subnets in Shrewsoft
> config according to this :
> https://dl.dropbox.com/u/60175032/Juniper_Config/juniper_linux2.png
>
> I see this in Shrewsoft logs when it is responding to same
> configuration from Netscreen :
> 13/01/24 12:52:17 ii : phase2 rejected, no matching inbound policy found
> 13/01/24 12:52:17 ii : - loc ANY:12.12.12.0/24:* -> ANY:192.168.1.0/24:*
> 13/01/24 12:52:17 ii : - rmt ANY:192.168.1.0/24:* -> ANY:12.12.12.0/24:*
>
> My shrewsoft config :
> # sample client iked.conf file
> daemon
> {
> # bind to ports
>
> socket ike 500;
> socket natt 4500;
>
> # log output
>
> log_level info;
>
> log_file "/var/log/iked/iked.log";
> # pcap_decrypt "/var/log/iked/ike-decrypt.pcap";
> # pcap_encrypt "/var/log/iked/ike-encrypt.pcap";
>
> # retry settings
>
> retry_delay 10;
> retry_count 2;
> }
>
> peer 10.103.2.75
> {
> contact responder;
> exchange aggressive;
> peerid local address;
> peerid remote address;
> authdata psk "1234567890";
> plcy_mode compat;
>
> proposal isakmp
> {
> auth mutual_psk;
> ciph 3des;
> hash sha1;
> }
>
> proposal esp
> {
> ciph 3des;
> hmac sha1;
> dhgr 2;
> }
> }
>
> On Thursday 24 January 2013 09:50:29 AM IST, Philippe Vouters wrote:
>> An good document from Juniper regarding the topic I am focusing
>> Elison's attention onto can be found
>> http://kb.juniper.net/kb/documents/public/Performance/ns_perf.pdf
>>
>> Philippe Vouters (Fontainebleau/France)
>> URL: http://vouters.dyndns.org/
>> SIP: sip:Vouters at sip.linphone.org
>>
>> Le 24/01/2013 04:36, Philippe Vouters a écrit :
>>> An observed fact that Elison may exploit more digging into. Is there
>>> any valid network reason why his Netscreen runs emit smaller UDP
>>> packets in the aggressive phase, needing two to inform Libreswan of
>>> all its payloads, compared to the much larger UDP corresponding
>>> packets I observe on my side running Shrew ?
>>>
>>> Philippe Vouters (Fontainebleau/France)
>>> URL: http://vouters.dyndns.org/
>>> SIP: sip:Vouters at sip.linphone.org
>>>
>>> Le 23/01/2013 23:22, Nick Howitt a écrit :
>>>> I've been watching this thread a bit and can I just make a point? So
>>>> far it has been shown that Shrew VPN behaves in a manner compatible
>>>> with LibreSwan. What you have not established is correct if the
>>>> LibreSwan is correct in its response to Netscreen. A valid test
>>>> would be between Shrew and Netscreen to see how the Shrew client
>>>> responds to the Netscreen case. It may be that the Shrew client
>>>> works with both scenarios. This would then indicate there may be a
>>>> standards issue with LibreSwan - but it still does not point you to
>>>> the standard.
>>>>
>>>> Regards,
>>>>
>>>> Nick
>>>>
>>>> On 23/01/2013 14:20, Philippe Vouters wrote:
>>>>> Elison,
>>>>>
>>>>> I have NOT YET read any strong evidence in the RFC's stored on
>>>>> Shrew Inc Web site (URL provided) that the second aggressive packet
>>>>> MUST be encrypted and that all payloads MUST be sent in the first
>>>>> unencrypted aggressive packet.
>>>>>
>>>>> If you succeed to find such an evidence, this will mean
>>>>> Libreswan/Openswan state machine algorithm which is the heart all
>>>>> the code is based onto is completely wrong.
>>>>>
>>>>> Philippe Vouters (Fontainebleau/France)
>>>>> URL: http://vouters.dyndns.org/
>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>
>>>>> Le 23/01/2013 14:45, Elison Niven a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> Yes you are right that there is no conclusive proof that who is
>>>>>> right in their implementation here, and that can only be reached
>>>>>> after reading the RFC's in detail.
>>>>>>
>>>>>> IMHO, I see three Vendors supporting this behavior on aggressive
>>>>>> mode so we might run into some standard/document/draft that
>>>>>> documents this.
>>>>>>
>>>>>> However, I have yet to find one !
>>>>>>
>>>>>> On Wednesday 23 January 2013 04:45 PM, Philippe Vouters wrote:
>>>>>>> Dear Elison,
>>>>>>>
>>>>>>> The real problem which seems to appear is that Netscreen sends in
>>>>>>> the
>>>>>>> second aggressive packet another payload in clear. Provided
>>>>>>> Libreswan/Openswan would accept such a second agressive payload in
>>>>>>> clear, this would completly break the Libreswan/Openswan logic
>>>>>>> which is
>>>>>>> a state machine transitioning from one from one state to a
>>>>>>> successive one.
>>>>>>>
>>>>>>> As far as it looks, Shrew sends all its payloads in clear in the
>>>>>>> very
>>>>>>> first packet. Because its second aggressive packet contains
>>>>>>> encrypted
>>>>>>> data with flags=1, I cannot tell what is this second packet
>>>>>>> content from
>>>>>>> the Wireshark trace.
>>>>>>>
>>>>>>> Either you or I should read in detail all the RFCs on the Shrew
>>>>>>> Soft Web
>>>>>>> site I mentioned, you or I would surely tell who among
>>>>>>> Shrew/Libreswan
>>>>>>> on one side and Netscreen/Fortigate, Netscreen/Sonicwall on the
>>>>>>> other
>>>>>>> side is absolutely right.
>>>>>>>
>>>>>>> Between you and me, the fact that it works between Netscreen and
>>>>>>> Fortigate or Sonicwall is indeed not a definite proof. Software
>>>>>>> history
>>>>>>> highlights lots of workarounds to bugs. In the Libreswan
>>>>>>> /Openswan case
>>>>>>> and provided it fully respects the IPSec RFCs, I can't imagine
>>>>>>> Libreswan
>>>>>>> able to correctly working around this Netscreen case. As I said
>>>>>>> above,
>>>>>>> Libreswan/Openswan is essentially a state machine.
>>>>>>>
>>>>>>> Philippe Vouters (Fontainebleau/France)
>>>>>>> URL: http://vouters.dyndns.org/
>>>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>>>
>>>>>>> Le 23/01/2013 10:53, Elison Niven a écrit :
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Yes that is what I indeed wanted to confirm.
>>>>>>>> However, if you recall correctly, as I had stated earlier, This
>>>>>>>> same
>>>>>>>> setup works fine with :
>>>>>>>> 1) Netscreen to Fortigate
>>>>>>>> 2) Netscreen to Sonicwall
>>>>>>>>
>>>>>>>> Here also Netscreen is sending the 2nd packet as not encrypted
>>>>>>>> ,(Flags
>>>>>>>> =0) and the other devices accept it.
>>>>>>>> Is Libreswan missing some RFC/protocol that the other vendors
>>>>>>>> are using?
>>>>>>>>
>>>>>>>> On Wednesday 23 January 2013 03:04:09 PM IST, Philippe Vouters
>>>>>>>> wrote:
>>>>>>>>> Dear Elison,
>>>>>>>>>
>>>>>>>>> When comparing your Wireshark trace with a corresponding
>>>>>>>>> Wireshark
>>>>>>>>> trace running Shrew VPN client, the problem is indeed visible
>>>>>>>>> on the
>>>>>>>>> second Aggressive packet sent by Netscreen. It has flags=0 when
>>>>>>>>> Shrew
>>>>>>>>> sets it to 1. Bit 1 of flags means encrypted.
>>>>>>>>>
>>>>>>>>> So there is definitely a bug on Netscreen side not respecting the
>>>>>>>>> RFCs. If you need information onto the whole set of RFCs, go to
>>>>>>>>> http://www.shrew.net/static/help-2.1.x/vpnhelp.htm?IPSecurity.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Philippe Vouters (Fontainebleau/France)
>>>>>>>>> URL: http://vouters.dyndns.org/
>>>>>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>>>>>
>>>>>>>>> Le 23/01/2013 05:05, Elison Niven a écrit :
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Here are logs with plutodebug=all :
>>>>>>>>>> http://pastebin.com/rVnGjiut
>>>>>>>>>>
>>>>>>>>>> If you need the wireshark capture, it is here :
>>>>>>>>>> https://dl.dropbox.com/u/60175032/Netscreen-Libreswan-Aggr.pcap
>>>>>>>>>>
>>>>>>>>>> On Wednesday 23 January 2013 02:13:58 AM IST, Philippe Vouters
>>>>>>>>>> wrote:
>>>>>>>>>>> I may also accept "both" as a valid answer. In which case,
>>>>>>>>>>> which side,
>>>>>>>>>>> from Netscreen or Libreswan, is supposed to have modified this
>>>>>>>>>>> smc->flags variable the last when it comes into the routine
>>>>>>>>>>> process_packet ???? Shouldn't process_packet be better
>>>>>>>>>>> renamed to
>>>>>>>>>>> process_incoming_packet ???
>>>>>>>>>>>
>>>>>>>>>>> Philippe Vouters (Fontainebleau/France)
>>>>>>>>>>> URL: http://vouters.dyndns.org/
>>>>>>>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>>>>>>>
>>>>>>>>>>> Le 22/01/2013 21:22, Philippe Vouters a écrit :
>>>>>>>>>>>> Paul,
>>>>>>>>>>>>
>>>>>>>>>>>> You succeeded to totally confuse me in your successive
>>>>>>>>>>>> explanations
>>>>>>>>>>>> for my actual understanding of Elison's problem. This is my
>>>>>>>>>>>> only
>>>>>>>>>>>> question to you after this mail of yours below:
>>>>>>>>>>>> Which side, Netscreen or Libreswan, is supposed to set
>>>>>>>>>>>> smc->flags in
>>>>>>>>>>>> the code extract I focus onto ???? Only one among the three
>>>>>>>>>>>> possible
>>>>>>>>>>>> answers I accept : "don't know/not sure", "Netscreen",
>>>>>>>>>>>> "Libreswan".
>>>>>>>>>>>>
>>>>>>>>>>>> Philippe Vouters (Fontainebleau/France)
>>>>>>>>>>>> URL: http://vouters.dyndns.org/
>>>>>>>>>>>> SIP: sip:Vouters at sip.linphone.org
>>>>>>>>>>>>
>>>>>>>>>>>> Le 22/01/2013 20:13, Paul Wouters a écrit :
>>>>>>>>>>>>> On Tue, 22 Jan 2013, Philippe Vouters wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Can you give me with no hesitation which actual state
>>>>>>>>>>>>>> corresponds to
>>>>>>>>>>>>>> OAKLEY_AUTH_ROOF + 2 ? From the lecture of Libreswan
>>>>>>>>>>>>>> source code,
>>>>>>>>>>>>>> getting this certainty is not trivial.
>>>>>>>>>>>>>> OAKLEY_AUTH_ROOF + 2 conditions this loglog'ed message:
>>>>>>>>>>>>>
>>>>>>>>>>>>> These are just defines,
>>>>>>>>>>>>>
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_ALL_AUTH
>>>>>>>>>>>>> LRANGE(0,
>>>>>>>>>>>>> OAKLEY_AUTH_ROOF-1)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_INITIATOR
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 0)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define
>>>>>>>>>>>>> SMF_FIRST_ENCRYPTED_INPUT
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 1)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_INPUT_ENCRYPTED
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 2)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_OUTPUT_ENCRYPTED
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 3)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define
>>>>>>>>>>>>> SMF_RETRANSMIT_ON_DUPLICATE
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 4)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_REPLY
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 5)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define
>>>>>>>>>>>>> SMF_RELEASE_PENDING_P2
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 6)
>>>>>>>>>>>>> libreswan/programs/pluto/ikev1.c:#define SMF_XAUTH_AUTH
>>>>>>>>>>>>> LELEM(OAKLEY_AUTH_ROOF + 7)
>>>>>>>>>>>>>
>>>>>>>>>>>>> They are used for our own defines. There is probably a good
>>>>>>>>>>>>> and
>>>>>>>>>>>>> smart
>>>>>>>>>>>>> reason why Hugh originally based them on values >
>>>>>>>>>>>>> OAKLEY_AUTH_ROOF, but
>>>>>>>>>>>>> I don't know them.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> smc in the code extract above is nothing but:
>>>>>>>>>>>>>> smc = md->smc;
>>>>>>>>>>>>>> and as per your explanation on md, I quote you:
>>>>>>>>>>>>>> "
>>>>>>>>>>>>>> md is the message digest, the stream of bytes from the
>>>>>>>>>>>>>> incoming
>>>>>>>>>>>>>> packet.
>>>>>>>>>>>>>> "
>>>>>>>>>>>>>> smc->flags should have been set by the Netscreen side.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not entirely, smc is the state machine microcode. The
>>>>>>>>>>>>> struct md is
>>>>>>>>>>>>> defined as:
>>>>>>>>>>>>>
>>>>>>>>>>>>> struct msg_digest {
>>>>>>>>>>>>> struct msg_digest *next; /* for free list */
>>>>>>>>>>>>> chunk_t raw_packet; /* if encrypted, received
>>>>>>>>>>>>> packet
>>>>>>>>>>>>> before decryption */
>>>>>>>>>>>>> const struct iface_port *iface; /* interface on which
>>>>>>>>>>>>> message arrived */
>>>>>>>>>>>>> ip_address sender; /* where message came from
>>>>>>>>>>>>> (network
>>>>>>>>>>>>> order) */
>>>>>>>>>>>>> u_int16_t sender_port; /* host order */
>>>>>>>>>>>>> pb_stream packet_pbs; /* whole packet */
>>>>>>>>>>>>> pb_stream message_pbs; /* message to be processed */
>>>>>>>>>>>>> pb_stream clr_pbs; /* place to store decrypted
>>>>>>>>>>>>> packet */
>>>>>>>>>>>>> struct isakmp_hdr hdr; /* message's header */
>>>>>>>>>>>>> bool encrypted; /* was it encrypted? */
>>>>>>>>>>>>> enum state_kind from_state; /* state we started in */
>>>>>>>>>>>>> const struct state_microcode *smc; /* microcode for
>>>>>>>>>>>>> initial
>>>>>>>>>>>>> state (v1)*/
>>>>>>>>>>>>> const struct state_v2_microcode *svm; /* microcode for
>>>>>>>>>>>>> initial
>>>>>>>>>>>>> state (v2)*/
>>>>>>>>>>>>> bool new_iv_set;
>>>>>>>>>>>>> struct state *st; /* current state object */
>>>>>>>>>>>>> struct state *pst; /* parent state object (if any) */
>>>>>>>>>>>>>
>>>>>>>>>>>>> enum phase1_role role;
>>>>>>>>>>>>> msgid_t msgid_received;
>>>>>>>>>>>>>
>>>>>>>>>>>>> pb_stream rbody; /* room for reply body (after
>>>>>>>>>>>>> header) */
>>>>>>>>>>>>> notification_t note; /* reason for failure */
>>>>>>>>>>>>> bool dpd; /* Peer supports RFC 3706 DPD */
>>>>>>>>>>>>> bool ikev2; /* Peer supports IKEv2 */
>>>>>>>>>>>>> bool event_already_set;
>>>>>>>>>>>>> stf_status result; /* temporary stored here for
>>>>>>>>>>>>> access by
>>>>>>>>>>>>> Tcl */
>>>>>>>>>>>>>
>>>>>>>>>>>>> # define PAYLIMIT 30
>>>>>>>>>>>>> struct payload_digest
>>>>>>>>>>>>> digest[PAYLIMIT],
>>>>>>>>>>>>> *digest_roof,
>>>>>>>>>>>>> *chain[ISAKMP_NEXT_ROOF];
>>>>>>>>>>>>> struct isakmp_quirks quirks;
>>>>>>>>>>>>> };
>>>>>>>>>>>>>
>>>>>>>>>>>>> I did not mean to say md is _just_ the packet. Apologies
>>>>>>>>>>>>> for the
>>>>>>>>>>>>> confusion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Swan mailing list
>>>>>>>>>>>> Swan at lists.libreswan.org
>>>>>>>>>>>> https://lists.libreswan.org/mailman/listinfo/swan
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best Regards,
>>>>>>>>>> Elison Niven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best Regards,
>>>>>>>> Elison Niven
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Swan mailing list
>>>>> Swan at lists.libreswan.org
>>>>> https://lists.libreswan.org/mailman/listinfo/swan
>>>>
>>>>
>>>
>>
>>
>>
>
> --
> Best Regards,
> Elison Niven
>
>
More information about the Swan
mailing list