Re: [opennhrp-devel] ISAKMP Dead Peer Detection with Cisco only funtions if a static peer mapping is defined

[Jean-Francois D. <jf...@gm...>]

Cool, one more bug squashed ;)

On Tue, Dec 13, 2011 at 9:58 PM, Frank Renwick <fre...@ce...> wrote:
> Jean,
>
> I apologize for the delay.  The suggested fix, which was to make a change in
> the function 'intident_r1send' in src/racoon/isakmp_ident.c, worked well.
> The change you suggested reverts back to ipsec-tools 0.7.0 behavior as you
> mentioned, and in 0.7.0 ipsec-tools sends the DPD vendor ID based on the
> racoon.conf configuration file, not based on an event driven scenario.  As
> you showed us, the Cisco Initiator is sending the DPD Vendor ID in MM3,
> which was not "acceptable" to ipsec-tools 0.8.0.
>
> I contacted the DPD developer, Yvan Vanhullebus, and let him know that this
> forum provided assistance, and what the assistance was.  He agreed to push
> the required change into future versions.  He mentioned that strictly
> speaking, Cisco's behavior in this matter does not break RFC compliance.  He
> mentioned that the Cisco could send the Vendor ID in the first exchange, but
> RFC 3706 has no 'MUST' or even 'SHOULD' for this.
>
> Finally:
>
> I ran through a test trial once the change was made and posted the results
> to the same ftp site:
>
> ftp://64.160.64.46/ (username: temp, password: temp).  The new log files and
> trace file are in the directory titled
> 'trial2-with-modifiec-ipsec-tools-0.8.0'
>
> The events in this trial are:
> 20:26:00 -- racoon and opennhrp started  (The cisco hub and spoke
> were started several minutes before this)
>
> 20:26:30 -- opennhrp node initiates a spoke-to-spoke connection with the
> cisco spoke by
> issuing a ping on the opennhrp spoke  (specifically, ping 10.0.2.1)
> 20:27:30 -- disconnect the link between N1 and the opennhrp host
> 20:29:00 -- reconnect the link
>
> Thanks very much for all the support with this issue.
>
> frank
>
> end test after ISAKMP re-negotiation and pin resumes.  I verified that ESP
> traffic
> resumed between the N1 Cisco Spoke and the opennhrp spoke.
>
>> 1) (0.8 specific):
>> ===
>> -> add the vendor ID in MM2 as responder even if we didnt got it in MM1:
>>
>> file: src/racoon/isakmp_ident.c, patch the following (line 1030 in my
>> file)
>> function:  intident_r1send(iph1, msg)
>>
>> #ifdef ENABLE_DPD
>>    if (iph1->dpd_support) {
>>
>> by
>>
>> #ifdef ENABLE_DPD
>> (iph1->rmconf == NULL || iph1->rmconf->dpd) {
>
> -----Original Message-----
> From: Jean-Francois Dive [mailto:jf...@gm...]
> Sent: Tuesday, December 06, 2011 14:27
> To: Frank Renwick
> Cc: Artem Makhutov; ope...@li...
> Subject: Re: [opennhrp-devel] ISAKMP Dead Peer Detection with Cisco only
> funtions if a static peer mapping is defined
>
> After compiling it, i realize the second part is not needed, it is handled
> already (the one in int ident_r2recv)
>
> J.
>
> On Tue, Dec 6, 2011 at 10:56 PM, Jean-Francois Dive <jf...@gm...>
> wrote:
>> Well Frank,
>>
>> I jumped too fast to conclusion: i looked at the fedora to hub packet
>> traces, mixed up the ip addresses of which is which ... and went the
>> wrong way. more later on the vendor id payload in which main mode
>> packet story.
>>
>> Back to the real connection: in the pcap traces:
>>
>> frame 53: ios spoke (10.0.0.6) initiate towards fedora (10.0.0.26), no
>>  DPD vendor ID payload
>> frame 54: fedora replies, no vendor ID either.
>> frame 55: ios send MM3 and adds more vendor ID payloads, DPD included.
>>
>> This last point didnt made sense and didnt matched what i read in the
>> source of ipsec-tools 0.7. I downloaded 0.8 and .. well the logic in
>> the code changed:
>>
>> -> in 0.7, the decision to add or not the vendor ID is MM2 based on a
>> flag being on off, driven by the remoteconf configuration (the remote
>> peer cfg file construct).
>> -> in 0.8, the same decision is based on the fact that we got before
>> the DPD vendor id in MM1 (and if we are configured too).
>>
>> What i thought confused IOS actually confused racoon and I am confused
>> on why IOS sends this serie of vendor ID later.
>>
>> The issue remains the same: racoon sends DPD's that IOS ignores
>> because it didnt received the DPD vendor ID from fedora.
>>
>> Now the fix. I have not tested this as i dont have an easy 12.4.15T to
>> test with from where i am.
>>
>> racoon, whatever version, does not handle this case properly: it will
>> ignore the vendor ID's received in MM3 when responder.
>>
>> the fix is in 2 places in the code
>>
>> 1) (0.8 specific):
>> ===
>> -> add the vendor ID in MM2 as responder even if we didnt got it in MM1:
>>
>> file: src/racoon/isakmp_ident.c, patch the following (line 1030 in my
>> file)
>> function:  intident_r1send(iph1, msg)
>>
>> #ifdef ENABLE_DPD
>>    if (iph1->dpd_support) {
>>
>> by
>>
>> #ifdef ENABLE_DPD
>> (iph1->rmconf == NULL || iph1->rmconf->dpd) {
>>
>>
>> 2) handle the vendor ID in MM3:
>> ===
>> file: src/racoon/isakmp_ident.c, patch the following (line 1191 in my
>> file)
>> function:  intident_r2recv(iph1, msg)
>>
>>            /* passthrough to default... */ #endif
>>            default:
>>
>> by:
>>
>>            /* passthrough to default... */ #endif
>>        case ISAKMP_NPTYPE_VID:
>>            int vid_numeric = check_vendorid(pa->ptr);
>>            if (vid_numeric == VENDORID_DPD && iph1->rmconf->dpd)
>>                iph1->dpd_support=1;
>>
>>        default:
>>
>>
>> I think that will fix your problem (untested)
>>
>> now, on the IOS side, this behavior might have a good reason which are
>> probably linked to the way the configuration is looked up within the
>> IKE implementation.
>>
>> Tell me how it goes.
>>
>> J.
>>
>> On Sun, Dec 4, 2011 at 7:18 PM, Frank Renwick <fre...@ce...> wrote:
>>> Thanks for taking such a close look at this.  The log files you asked
>>> for are attached.  I'll state again that if this is not the right
>>> forum for this question please feel free to ask me to stop.
>>>
>>> The description of the problem: When DPD is configured on the
>>> opennhrp spoke, dynamic spoke-to-spoke tunneling with a cisco spoke
>>> initiates but then times out after 45 seconds.  (If DPD is disabled
>>> on the opennhrp spoke, the dynamic spoke-to-spoke tunnel works
>>> without any issues discovered to
>>> date.)
>>>
>>> Observation: In the spoke-to-spoke dynamic tunnel setup, in my test
>>> lab, I am using ping from the opennhrp spoke to initiate the
>>> spoke-to-spoke tunnel with the cisco spoke.  In every test I've run,
>>> the first ISAKMP packet seen on the wire between the two spokes is
>>> from the Cisco spoke to the opennhrp spoke.  As such, it appears that
>>> the failed DPD negotiation may be related to the Cisco being the
>>> initiator.  I'm not sure about this, but when the opennhrp spoke
>>> initiated the IKE exhange with the Cisco hub, DPD negotiation is
> successful.
>>>
>>> The attached files are:
>>>
>>> Network.pdf:  physical and logical topology views of the test network
>>> Hub-configs.txt: cisco hub 'sh run', 'sh ver' and 'sh dmvpn detail'
>>> N1-configs.txt: cisco spoke 'sh run', 'sh ver' and 'sh dmvpn detail'
>>> Opennhrp.conf,racoon.conf: opennhrp spoke configs
>>>
>>> Log files:
>>> Trace.pcap:  sniffer trace captured on the opennhrp spoke
>>> Logfile: racoon log file capture on the opennhrp spoke
>>> Hub-debug-crypto-isakmp.txt: isakmp debugging on the cisco hub
>>> N1-debug-crypto-isakmp.txt: isakmp debuggin on the cisco spoke
>>>
>>> When looking through the log files, which have time synchronization,
>>> the following times are relevant:
>>>
>>> 17:49:00 -- racoon and opennhrp started  (The cisco hub and spoke
>>> were started several minutes before this) 17:50:00 -- opennhrp node
>>> initiates a spoke-to-spoke connection with the cisco spoke by issuing
>>> a ping on the opennhrp spoke  (specifically, ping
>>> 10.0.2.1)
>>> 17:50:45 -- the ping to the cisco spoke begins to timeout 17:51:00 --
>>> end test
>>>
>>> frank
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Jean-Francois Dive [mailto:jf...@gm...]
>>> Sent: Sunday, December 04, 2011 01:08
>>> To: Frank Renwick
>>> Cc: Artem Makhutov; ope...@li...
>>> Subject: Re: [opennhrp-devel] ISAKMP Dead Peer Detection with Cisco
>>> only funtions if a static peer mapping is defined
>>>
>>> hello Frank,
>>>
>>> The log message you point in the IOS logs are not relevant. There are
>>> 2 key differences here between the 2 logs you showed:
>>>
>>> -> In the failing state, IOS is the initiator In the failing states,
>>> -> there are 2 phase 1 negotiated between the 2
>>> devices, the initial contact notify payload should drive the delete
>>> of the old one but it seems we are still using it on the racoon side
>>> (seems, hard to make a 100% call from the data we have).
>>>
>>> It  is somehow classical that an ike negotiation works ok when
>>> initiated from one side and could fail when initiated from the other.
>>>
>>> it would be good to have a little more data about the 3 devices we
>>> see: 10.0.0.6 (cisco IOS, hub i guess?), 10.0.0.26 and 10.0.0.2., and
>>> the dmvpn configuration:
>>>
>>> on IOS, please collect:
>>>
>>> show version
>>> show dmvpn
>>> show run (interface tunnel X), isakmp and ipsec profile are ok
>>> otherwise you would have a different type of errors.
>>>
>>> and a description of exactly who is initiating/responding to who:
>>> this depends on the dmvpn phase you are using (phase 2 or phase 3)
>>> and therefore the nhrp config + routes distribution of the subnets
>>> behind the spoke (do your spokes are a summary route pointing to the
>>> hub and use nhrp redirect or do you have each routes pointing to each
> spoke's tunnel addresses) ?
>>>
>>> to troubleshoot this, it is important to start with a known state adn
>>> then trigger the problem, collecting precisely the debugs and capture
>>> (sniffer trace could help between IOS and failing openhrp device),
>>> with all the devices time sync'ed to correlate the logs (seems to be
>>> off in the logs you showed).
>>>
>>> Hope this help.
>>>
>>> J.
>>>
>>> PS: my guts feeling tells me racoon does not purge the old phase 1,
>>> IOS uses the new one and purged the old, racoon send DPD on the old,
>>> does not get responses, flushes the entire session.
>>>
>>> On Sat, Dec 3, 2011 at 8:40 PM, Frank Renwick <fre...@ce...>
> wrote:
>>>>
>>>> Sorry, I forgot to attach the capture files.
>>>>
>>>> Frank
>>>>
>>>> -----Original Message-----
>>>> From: Artem Makhutov [mailto:ar...@ma...]
>>>> Sent: Saturday, December 03, 2011 03:05
>>>> To: ope...@li...
>>>> Subject: Re: [opennhrp-devel] ISAKMP Dead Peer Detection with Cisco
>>>> only funtions if a static peer mapping is defined
>>>>
>>>> Hello Frank,
>>>>
>>>> Frank Renwick schrieb:
>>>>> Hello,
>>>>> I'm not sure if this is the proper forum for this question as it
>>>>> may be an
>>>> ipsec-tools related matter.
>>>>> I have a network with a Cisco DMVPN Hub, several Cisco DMVPN
>>>>> spokes, and
>>>> one (at present) opennhrp spoke. As long as Dead Peer Detection
>>>> (DPD) is disabled in racoon.conf, everything is functional,
>>>> including spoke-to-spoke GRE and IPSec tunnels.
>>>>> I am using DPD in the racoon.conf file and on the Cisco routers to
>>>>> assist
>>>> with periodic network outages that occur in the network environment
>>>> I am working in. Without DPD, network outages and/or router reboots
>>>> can result in mis-matched SAs after network communications are
> re-established.
>>>>> The issue is that when using DPD, a Cisco router only properly
>>>>> negotiate
>>>> the DPD capability with the opennhrp node IF the opennhrp node uses
>>>> a static peer mapping for the Cisco. As such, I am forced to place
>>>> static peer mappings for all Cisco nodes in the opennhrp.conf file
>>>> in order to get DPD working as desired. Note that I do NOT need to
>>>> define static mappings on the Cisco spokes, only on the opennhrp spoke.
>>>>> The DPD related configurations I am using are:
>>>>> In racoon.conf:
>>>>> remote anonymous {
>>>>> dpd_delay 20;
>>>>> dpd_retry 5;
>>>>> }
>>>>> On the Cisco routers:
>>>>> crypto isakmp keepalive 20 5 periodic Any ideas related to this
>>>>> issue would be greatly appreciated. If
>>>> additional configuration snippets or packet captures would be
>>>> useful, don't hesitate to ask.
>>>>> frank
>>>>
>>>> I had also DPD and reconnection problems initially.
>>>>
>>>> They were caused that I have created the gre1 interface by device
>>>> name and not by IP adress:
>>>>
>>>> ip tunnel add mode gre key 1234 ttl 64 dev eth0
>>>>
>>>> When you do this that way you need to change racoon-ph1dead.sh from
>>>>
>>>> opennhrpctl cache lowerdown nbma $REMOTE_ADDR local-nbma $LOCAL_ADDR
>>>>
>>>> to
>>>>
>>>> opennhrpctl cache lowerdown nbma $REMOTE_ADDR dev gre1
>>>>
>>>> This solved all my issues.
>>>>
>>>> Regards, Artem
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> --
>>>> -------- All the data continuously generated in your IT
>>>> infrastructure contains a definitive record of customers,
>>>> application performance, security threats, fraudulent activity, and
>>>> more. Splunk takes this data and makes sense of it. IT sense. And common
> sense.
>>>> http://p.sf.net/sfu/splunk-novd2d
>>>> _______________________________________________
>>>> opennhrp-devel mailing list
>>>> ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opennhrp-devel
>>>>
>
>