Has anyone filed a bug report or should I send this to bugs@?

Regards,
Jakob Alvermark

On 6 maj 2011, at 11:33, Jakob Alvermark wrote:

> 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
>

Jakob Alvermark
jakob.alverm...@bsdlabs.com
BSDLabs AB
Solna, Sweden
556759-7652

Reply via email to