[vpn-help] Regression in Linux shrew 2.1.7 -> OpenBSD 4.8+ roadwarrior VPN
Kevin VPN
kvpn at live.com
Wed Oct 12 21:43:57 CDT 2011
On 10/12/2011 12:56 PM, Zak Elep wrote:
> Hi! Sorry this took long, I had to find time to reconfigure the OpenBSD
> gateway.
>
> On Monday, September 12, 2011, Kevin VPN wrote:
>>
>> From the iked.log you provided, it seems that the gateway is not responding
>> the the Shrew client's request. Is there any chance you can view the log on
>> the OpenBSD gateway to see what it says about the incoming request?
>>
>> You could also run a packet capture on your Ubuntu box's outgoing interface
>> to see if the request is even being sent out.
>>
>
> At the OpenBSD gateway, I get these logs from isakmpd:
>
> Sep 10 15:07:09 XXXX isakmpd[15168]: transport_send_messages: giving up
> on exchange peer-default, no response from peer xxx.xxx.xxx.xxx:60771
>
> On a running attempt, these logs appear after every second resend attempt of
> the phase1 negotiation per connection attempt.
>
> Attached is the verbose isakmpd log from the gateway; I notice that the SA
> payload gets dropped right after the phase1 negotiation.
>
Hi Zak,
Based on the isakmpd log in this message and the iked.log from your
previous message, it appears that Shrew is sending packets to the
OpenBSD gateway (isakmpd shows message_recv), the OpenBSD is responding
(isakmpd message_send), but that the response packets are not getting to
the Shrew client. What this causes is Shrew to resend the request,
which is what is generating the isakmpd "message_recv: dropping setup
for existing SA" messages.
Perhaps this is a re-occurence/mutation of a previous kernel-related
problem. Check this link to see if changing the rp_filter as mentioned
here helps:
http://lists.shrew.net/pipermail/vpn-help/2008-November/000950.html
More information about the vpn-help
mailing list