A little more info:
I have now ENCDEBUG enabled on both ends in the lab.
When one tunnel fails I get the same error on both machines:
May 4 12:27:55 test1 /bsd: esp_input_cb(): authentication failed for packet
in SA xxx.xxx.xxx.97/84be7b20
May 4 12:27:18 test2 /bsd: esp_input_cb(): authentication failed for packet
in SA xxx.xxx.xxx.99/da1d3abb
ipsecctl -v -sa give no hints, everything looks normal:
esp tunnel from xxx.xxx.xxx.99 to xxx.xxx.xxx.97 spi 0x84be7b20 auth
hmac-sha2-256 enc aes
sa: spi 0x84be7b20 auth hmac-sha2-256 enc aes
state mature replay 16 flags 4
lifetime_cur: alloc 0 bytes 7968 add 1304504831 first 1304504875
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
address_src: xxx.xxx.xxx.99
address_dst: xxx.xxx.xxx.97
identity_src: type prefix id 0: xxx.xxx.xxx.99/32
identity_dst: type prefix id 0: xxx.xxx.xxx.97/32
src_mask: 255.255.255.0
dst_mask: 255.255.255.0
protocol: proto 0 flags 0
flow_type: type use direction in
src_flow: 192.168.31.0
dst_flow: 192.168.1.0
remote_auth: type rsa
esp tunnel from xxx.xxx.xxx.97 to xxx.xxx.xxx.99 spi 0xda1d3abb auth
hmac-sha2-256 enc aes
sa: spi 0xda1d3abb auth hmac-sha2-256 enc aes
state mature replay 16 flags 4
lifetime_cur: alloc 0 bytes 48864 add 1304504837 first 1304504838
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
address_src: xxx.xxx.xxx.97
address_dst: xxx.xxx.xxx.99
identity_src: type prefix id 0: xxx.xxx.xxx.97/32
identity_dst: type prefix id 0: xxx.xxx.xxx.99/32
src_mask: 255.255.255.0
dst_mask: 255.255.255.0
protocol: proto 0 flags 0
flow_type: type use direction in
src_flow: 192.168.1.0
dst_flow: 192.168.31.0
remote_auth: type rsa
On 2 maj 2011, at 21:59, MG wrote:
> On 5/2/2011 12:13 PM, Vijay Sankar wrote:
>> Per olof Ljungmark wrote:
>>> On 05/02/11 18:08, Robert wrote:
>>>> Hi,
>>>>
>>>> Same here, but between 2 hosts in the same subnet (very basic network
>>>> setup).
>>>> I was also waiting for 4.9 (and time to investigate...)
>>>
>>> We see same behaviour on 4.9 so upgrading will not help.
>>>
>>>> On Mon, 2 May 2011 13:30:34 +0000 (UTC)
>>>> Stuart Henderson <s...@spacehopper.org> wrote:
>>>>
>>>>> I see something similar which I've been trying to track down but not
>>>>> really succeeding. The thing we have in common is multiple subnets,
>>>>> I wonder if this is a factor...
>>>>>
>>>>>
>>>>> (and this setup has always been post-4.4 On 2011-05-02, Jakob Alvermark
<jakob.alverm...@bsdlabs.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am getting some strange problems with IPSEC tunnels.
>>>>>> There are 5 sites connected using IPSEC tunnels, which used to work
perfectly,
>>>>>> but since upgrading to 4.8 (from 4.4),
>>>>>> tunnels started failing, seemly at random intervals.
>>>>>> To investigate I set up two machines in the lab and they exhibit the
same
>>>>>> behavior:
>>>>>> After a seemingly random amount of time, when there is a renegotiation
of an
>>>>>> SA due to its lifetime expired,
>>>>>> traffic will stop flowing (I have a ping running). 'ipsecctl -sa' and
'netstat
>>>>>> -rn' shows everything as normal.
>>>>>> When that SA lifetime expires and a new SA is negotiated it comes back
again.
>>>>>>
>>>>>> I recompiled the kernel with 'option ENCDEBUG' and set
net.inet.ip.encdebug=1
>>>>>> and when it fails
>>>>>> I get 'esp_input_cb(): authentication failed for packet in SA
>>>>>> xxx.xxx.xxx.97/6e68c6ae'
>>>>>>
>>>>>> The machines are installed with stock OpenBSD 4.8, nothing special
about the
>>>>>> configuration.
>>>>>> ipsec.conf is very simple, just one line:
>>>>>>
>>>>>> ike esp from {192.168.1.9/24 172.16.1.0/24} to {192.168.31.0/24
>>>>>> 192.168.32.254} local xxx.xxx.xxx.97 peer xxx.xxx.xxx.99
>>>>>>
>>>>>> Public keys copied across, isakmpd started with flags "-K -v"
>>>>>>
>>>>>> Does anyone have any ideas about this?
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> Jakob Alvermark
>>>>>> jakob.alverm...@bsdlabs.com
>>>>>> BSDLabs AB
>>>>>> Solna, Sweden
>>>>>> 556759-7652
>>>
>>
>> FWIW, I have the following number of flows and tunnels using OpenBSD 4.8 at
the moment. I have not seen any problems when both peers are OpenBSD servers.
>>
>> Mon May 02 11:57:12 CPU@36.0C # ipsecctl -sa | grep -c flow
>> 160
>> Mon May 02 11:57:21 CPU@36.0C # ipsecctl -sa | grep -c tunnel
>> 254
>>
>> Approximately two months ago I had a similar situation to what you
described and sort of narrowed it down to the following:
>>
>> The peer site had Cisco ASA VPN concentrator and they had different subnets
with 172.16.0.0/24, 172.16.1.0/24, and so on to different customer networks.
At our end with OpenBSD, we had a subnet of 172.16.0.0/21 for our internal
network. Because the Cisco end could not change their subnet mask, we changed
the subnet mask on the OpenBSD box to 172.16.1.0/24 and allowed access only to
a few hosts with the address 172.16.1.xx and set up static routes from those
boxes to go through the OpenBSD box. The problems seemed to be isolated to the
internal hosts at the Cisco end that were NAT'ed out to a DMZ and were
accessing our network from the the ASA box located in their DMZ. We
reconfigured our firewall rules to allow all traffic to their network to flow
through and the problems stopped for a full three weeks. Unfortunately,
(apparently) they said that intermittent drops started again (even though we
had not made any changes at our end once everything was working properly),
blamed me for this problem and asked us to use a Cisco PIX router instead of
the OpenBSD box just for their access. So that is what we ended up doing since
I had no access to their Cisco gear and they did not have time to
troubleshoot.
>>
>>
> I am also experiencing random drops that last for approximately 14 minutes.
This is between two OpenBSD 4.8 boxes. Pinging devices through the IPSec
tunnel begins to fail but pinging the external IP address works fine during
the outages. I'm new to tunnels so I'm not sure how to troubleshoot exactly.
I have multiple subnets on both sides of the f/ws. I was getting cookie
errors in /var/log/messages but I don't see them in my recent logs and my log
files have turned over.
>
Jakob Alvermark
jakob.alverm...@bsdlabs.com
BSDLabs AB
Solna, Sweden
556759-7652
