[Swan] Can you elaborate on this ?

Elison Niven elison.niven at cyberoam.com
Thu Jan 24 09:28:02 EET 2013


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