[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