Apologies for the previous empty message.
On Saturday 09 January 2010 08:57, Toni Mueller wrote:
> Hi,
>
> On Tue, 05.01.2010 at 12:44:49 -0800, Jeff Simmons
<[email protected]> wrote:
> > <results elided>
> > Encap:
> > Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
> > <expected ecap routes elided>
> > 0/0 0 0/0 0 0 gatewayIP/50/use/in
> > 0/0 0 0/0 0 0
> > gatewayIP/50/require/out
>
> I've seen this routing entry, too, only _immediately_ after connect,
> and am *very* interested in talking to qualified people to solve this
> issue. Imho, this issue has nothing to do with Sonicwall or Cisco.
In my case, it's definitely the Sonicwall (partly, the Cisco doesn't seem to
be involved). What happens is, we set up a VPN and everything proceeds
normally for anywhere from about 4 to 9 hours. Then the SonicWall suddenly,
for no discernable reason, sends the following down the pipe:
15:36:26.089180 B.B.B.B.isakmp > A.A.A.A.isakmp: [udp sum ok] isakmp v1.0 ex
change QUICK_MODE
cookie: a2e097b5de0095ba->5ffb617eaf801be5 msgid: f3c98789 len: 172
payload: HASH len: 24
payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4
xforms: 1 S
PI: 0xd4524377
payload: TRANSFORM len: 32
transform: 1 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 00000e10
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
attribute ENCAPSULATION_MODE = TUNNEL
attribute KEY_LENGTH = 128
payload: NONCE len: 24
payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0
payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0]
(id 1, len 200)
15:36:26.089370 A.A.A.A.isakmp > B.B.B.B.isakmp: [udp sum ok] isakmp v1.0 ex
change INFO
cookie: a2e097b5de0095ba->5ffb617eaf801be5 msgid: 043ce92b len: 64
payload: HASH len: 24
payload: NOTIFICATION len: 12
notification: INVALID ID INFORMATION [ttl 0] (id 1, len 92)
So A.A.A.A (OpenBSD) correctly ascertains that this is probably a bad idea,
and rejects the proposal. Now, if there's only one connection (i.e. a single
host to host, or host to subnet) running between these two gateways, the
system handles things, and eventually a correct A.A.A.A initiated proposal
goes back, and everything returns to normal. But with three connections,
eventually A.A.A.A accepts the proposal, hoses all network connections on the
box, and requires an intervention.
Unfortunately, this is a high-traffic 24/7/365 in-production firewall/VPN
gateway at a client of mine (and the connection to a separate company they do
business with), so testing things that may crash the box is frowned on by my
clients. I haven't yet been able to catch logs of the actual acceptance of
the 0.0.0.0 routes yet.
So I really don't know a) what the hell the Sonicwall thinks it's doing, or b)
why the OpenBSD box occasionally goes along with it.
If you find out anything, I'd appreciate hearing about it.
--
Jeff Simmons [email protected]
Simmons Consulting - Network Engineering, Administration, Security
"You guys, I don't hear any noise. Are you sure you're doing it right?"
-- My Life With The Thrill Kill Kult
