[Openswan Users] OSX 10.4.5 maybe :)

Brett Curtis dashnu at gmail.com
Tue Feb 21 10:11:30 CET 2006 

Well I tried  xl2tpd.. switch out my current gentoo l2tpd with it and  
still have the same issues. My best guess would be an issue with ppp.  
Did the xl2tpd fix the issue for you ? They both work fine for  
windows clients.. So who know it could be another OSX issue.

Thanks.
On Feb 17, 2006, at 10:55 AM, Christophe Ngo Van Duc wrote:

> Hi,
>
>   Yes I have exactly the same problem, I was testing it during the  
> past 2 days. Exactly one hour and I loose the connection.
>   I am going to test the xl2tpd suggested by Paul and see.
>
> Cheers,
> Christophe.
>
>
> On 2/17/06 9:21 AM, "Brett Curtis" <dashnu at gmail.com> wrote:
>
>> Wondering if you figured out why you are losing your connect. I  
>> seem to loose mine after about an hour. It seems to be an l2tpd or  
>> ppp problem.
>>
>> Some logs.. are yours reflecting the same errors?
>>
>> Feb 15 14:01:08 defender pppd[21204]: rcvd [LCP EchoReq id=0x2a  
>> magic=0xc6ac4467]
>> Feb 15 14:01:08 defender pppd[21204]: sent [LCP EchoRep id=0x2a  
>> magic=0x85f75c48]
>> Feb 15 14:01:53 defender l2tpd[1939]: control_xmit: Maximum  
>> retries exceeded for tunnel 54320.  Closing.
>>
>> I get several of those pppd logs. It seems that the ipsec connect  
>> is fine through this series of events.
>>
>> Versions..
>>
>> Gentoo Linux 2.6.11-hardened-r15
>> openswan-2.4.4
>> l2tpd-0.70_pre20031121
>> ppp-2.4.2-r15
>>
>> Thanks.
>>
>>
>>
>> On Feb 15, 2006, at 11:44 AM, Christophe Ngo wrote:
>>
>>> Hi,
>>>
>>>    I’ve been connecting today as a roadwarrior with a 10.4.5  
>>> behind an DSL router and NATed
>>>
>>>    What I’ve found so far:
>>>  pluto[17507]: packet from x.x.x.x:500: received Vendor ID  
>>> payload [RFC 3947] method set to=109
>>>  pluto[17507]: packet from x.x.x.x:500: received Vendor ID  
>>> payload [draft-ietf-ipsec-nat-t-ike] method set to=110
>>>  pluto[17507]: packet from x.x.x.x:500: received Vendor ID  
>>> payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already  
>>> using method 110
>>>  pluto[17507]: packet from x.x.x.x:500: received Vendor ID  
>>> payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already  
>>> using method 110
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: responding to  
>>> Main Mode from unknown peer 200.88.223.131
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: transition from  
>>> state STATE_MAIN_R0 to state STATE_MAIN_R1
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: STATE_MAIN_R1:  
>>> sent MR1, expecting MI2
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: ignoring Vendor  
>>> ID payload [KAME/racoon]
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: NAT-Traversal:  
>>> Result using RFC 3947 (NAT-Traversal): peer is NATed
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: transition from  
>>> state STATE_MAIN_R1 to state STATE_MAIN_R2
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: STATE_MAIN_R2:  
>>> sent MR2, expecting MI3
>>>  pluto[17507]: "L2TP-PSK-OLD"[45] x.x.x.x #108: Main mode peer ID  
>>> is ID_IPV4_ADDR: '10.0.0.3'
>>>  pluto[17507]: "L2TP-PSK-OLD"[46] x.x.x.x #108: deleting  
>>> connection "L2TP-PSK-OLD" instance with peer x.x.x.x {isakmp=#0/ 
>>> ipsec=#0}
>>>  pluto[17507]: "L2TP-PSK-OLD"[46] x.x.x.x #108: I did not send a  
>>> certificate because I do not have one.
>>>  pluto[17507]: "L2TP-PSK-OLD"[46] x.x.x.x #108: transition from  
>>> state STATE_MAIN_R2 to state STATE_MAIN_R3
>>>  pluto[17507]: | NAT-T: new mapping x.x.x.x:500/50339)
>>>  pluto[17507]: "L2TP-PSK-OLD"[46] x.x.x.x #108: STATE_MAIN_R3:  
>>> sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY  
>>> cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
>>>  pluto[17507]: "L2TP-PSK-NAT"[8] x.x.x.x #109: responding to  
>>> Quick Mode {msgid:ecd87ac6}
>>>  pluto[17507]: "L2TP-PSK-NAT"[8] x.x.x.x #109: transition from  
>>> state STATE_QUICK_R0 to state STATE_QUICK_R1
>>>  pluto[17507]: "L2TP-PSK-NAT"[8] x.x.x.x #109: STATE_QUICK_R1:  
>>> sent QR1, inbound IPsec SA installed, expecting QI2
>>>  pluto[17507]: "L2TP-PSK-NAT"[8] x.x.x.x #109: transition from  
>>> state STATE_QUICK_R1 to state STATE_QUICK_R2
>>>  pluto[17507]: "L2TP-PSK-NAT"[8] x.x.x.x #109: STATE_QUICK_R2:  
>>> IPsec SA established {ESP=>0x06bddbec <0xfc9d43dd xfrm=AES_128- 
>>> HMAC_SHA1 NATD= x.x.x.x:50339 DPD=none}
>>>
>>>    The strange thing I’ve noticed today is that the VPN  
>>> connection seems to drop when the DSL connection is used a lot by  
>>> the other computer (the 10.0.0.2) which is not connected to the VPN
>>>
>>>  Let me know if I can help test something for you.
>>>
>>>  Cheers,
>>>  Christophe
>>>
>>>  On 2/15/06 12:04 PM, "Brett Curtis" <dashnu at gmail.com> wrote:
>>>
>>>
>>>> Latest update Fix.. 10.4.5
>>>>
>>>>  -VPN connections to Cisco servers when using NAT
>>>>
>>>>  Hope they use the correct NAT-T now.. I will let you guys know.
>>>>
>>>>  /me reboots
>>>>
>>>>
>>>> _______________________________________________
>>>>  Users at openswan.org
>>>>  http://lists.openswan.org/mailman/listinfo/users
>>>>  Building and Integrating Virtual Private Networks with Openswan:
>>>>  http://www.amazon.com/gp/product/1904811256/104-3099591-2946327? 
>>>> n=283155
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users at openswan.org
>>> http://lists.openswan.org/mailman/listinfo/users
>>> Building and Integrating Virtual Private Networks with Openswan:
>>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327? 
>>> n=283155
>>>
>>
>>
>
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327? 
> n=283155

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20060221/72274f8b/attachment-0001.htm

More information about the Users mailing list