[Swan] Can you elaborate on this ?

Philippe Vouters philippe.vouters at laposte.net
Thu Jan 24 17:09:53 EET 2013


Elison,

To best understand Shrew and quickly get into may I refer you to
http://vouters.dyndns.org/tima/Linux-Shrew_VPN_Client-Installing_and_using_Shrew_VPN_client_on_Linux.html

To quickly start with Shrew , may I refer you to the .vpn file I document at
http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven-Part_2.html
The document included .vpn file may serve you as a starting model to 
correctly configure a Shrew site entry using qikea.

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