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
