D-Link DFL-260-IPS-12 Product Manual - Page 441

Note: L2TP with Microsoft Vista, Ike_invalid_payload, Ike_invalid_cookie, Payload_Malformed

Page 441 highlights

9.7.5. Specific Error Messages Chapter 9. VPN tunnels use different pre-shared keys, you will receive an "Incorrect pre-shared key" error message. The problem is solved if we reorder the list and move VPN-3 above L2TP. The gateway office3gw will be then matched correctly and VPN-3 will be the tunnel selected by NetDefendOS. 3. Ike_invalid_payload, Ike_invalid_cookie In this case the IPsec engine in NetDefendOS receives an IPsec IKE packet but is unable to match it against an existing IKE. If a VPN tunnel is only established on one side, this can be the resulting error message when traffic arrives from a tunnel that does not exist. An example would be if, for some reason, the tunnel has only gone down from the initiator side but the terminator still sees it as up. It then tries to send packets through the tunnel but when they arrive at the initiator it will drop them since no matching tunnel can be found. Simply remove the tunnel from the side that believes it is still up to solve the immediate problem. An investigation as to why the tunnel only went down from one side is recommended. It could be that DPD and/or Keep-Alive is only used on one side. Another possible cause could be that even though it has received a DELETE packet, it has not deleted/removed the tunnel. 4. Payload_Malformed This problem is very similar to the Incorrect pre-shared key problem described above. A possible reason is that the PSK is of the wrong TYPE on either side (Passphrase or Hex key). Verify that you are using the same type on both sides of the IPsec tunnel. If one side is using Hex and the other Passphrase, this is most likely the error message that you will receive. 5. No public key found This is a very common error message when dealing with tunnels that use certificates for authentication. Troubleshooting this error message can be very difficult as the possible cause of the problem can be quite extensive. Also it is very important to keep in mind that when dealing with certificates you may need to combine the ikesnoop logs with normal logs as ikesnoop does not give that much information about certificates, while normal logs can provide important clues as to what the problem could be. A good suggestion before you start to troubleshoot certificate based tunnels is to first configure it as a PSK tunnel and then verify that it can successfully establish, then move on to using Certificates. (Unless the configuration type prohibits that). The possible causes are as follows: • The certificate on either side is not signed by the same CA server. • The certificate's validity time has expired or it has not yet started to be valid. The latter can happen if the clock is set incorrectly on either the CA server or the NetDefend Firewall or they are in different time zones. • The NetDefend Firewall is unable to reach the Certificate Revocation List (CRL) on the CA server in order to verify if the certificate is valid or not. Double-check that the CRL path is valid in the certificate's properties. (Using the CRL feature could be turned off.) Make sure also that there is a DNS client configured in NetDefendOS in order for it to be able to correctly resolve the path to the CRL. Note: L2TP with Microsoft Vista With L2TP, Microsoft Vista tries by default to contact and download the CRL list, while Microsoft XP does not. This option can be turned off in Vista. 441

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313
  • 314
  • 315
  • 316
  • 317
  • 318
  • 319
  • 320
  • 321
  • 322
  • 323
  • 324
  • 325
  • 326
  • 327
  • 328
  • 329
  • 330
  • 331
  • 332
  • 333
  • 334
  • 335
  • 336
  • 337
  • 338
  • 339
  • 340
  • 341
  • 342
  • 343
  • 344
  • 345
  • 346
  • 347
  • 348
  • 349
  • 350
  • 351
  • 352
  • 353
  • 354
  • 355
  • 356
  • 357
  • 358
  • 359
  • 360
  • 361
  • 362
  • 363
  • 364
  • 365
  • 366
  • 367
  • 368
  • 369
  • 370
  • 371
  • 372
  • 373
  • 374
  • 375
  • 376
  • 377
  • 378
  • 379
  • 380
  • 381
  • 382
  • 383
  • 384
  • 385
  • 386
  • 387
  • 388
  • 389
  • 390
  • 391
  • 392
  • 393
  • 394
  • 395
  • 396
  • 397
  • 398
  • 399
  • 400
  • 401
  • 402
  • 403
  • 404
  • 405
  • 406
  • 407
  • 408
  • 409
  • 410
  • 411
  • 412
  • 413
  • 414
  • 415
  • 416
  • 417
  • 418
  • 419
  • 420
  • 421
  • 422
  • 423
  • 424
  • 425
  • 426
  • 427
  • 428
  • 429
  • 430
  • 431
  • 432
  • 433
  • 434
  • 435
  • 436
  • 437
  • 438
  • 439
  • 440
  • 441
  • 442
  • 443
  • 444
  • 445
  • 446
  • 447
  • 448
  • 449
  • 450
  • 451
  • 452
  • 453
  • 454
  • 455
  • 456
  • 457
  • 458
  • 459
  • 460
  • 461
  • 462
  • 463
  • 464
  • 465
  • 466
  • 467
  • 468
  • 469
  • 470
  • 471
  • 472
  • 473
  • 474
  • 475
  • 476
  • 477
  • 478
  • 479
  • 480
  • 481
  • 482
  • 483
  • 484
  • 485
  • 486
  • 487
  • 488
  • 489
  • 490
  • 491
  • 492
  • 493
  • 494
  • 495
  • 496
  • 497
  • 498
  • 499
  • 500
  • 501
  • 502
  • 503
  • 504
  • 505
  • 506
  • 507
  • 508
  • 509
  • 510
  • 511
  • 512
  • 513
  • 514
  • 515
  • 516
  • 517
  • 518
  • 519
  • 520
  • 521
  • 522
  • 523
  • 524
  • 525
  • 526
  • 527
  • 528
  • 529
  • 530
  • 531
  • 532
  • 533
  • 534
  • 535
  • 536
  • 537
  • 538
  • 539
  • 540
  • 541
  • 542
  • 543
  • 544
  • 545

tunnels use different pre-shared keys, you will receive an "
Incorrect pre-shared key
" error message.
The problem is solved if we reorder the list and move
VPN-3
above
L2TP
. The gateway
office3gw
will be then matched correctly and
VPN-3
will be the tunnel selected by NetDefendOS.
3.
Ike_invalid_payload, Ike_invalid_cookie
In this case the IPsec engine in NetDefendOS receives an IPsec IKE packet but is unable to match it
against an existing IKE.
If a VPN tunnel is only established on one side, this can be the resulting error message when traffic
arrives from a tunnel that does not exist. An example would be if, for some reason, the tunnel has
only gone down from the initiator side but the terminator still sees it as up. It then tries to send
packets through the tunnel but when they arrive at the initiator it will drop them since no matching
tunnel can be found.
Simply remove the tunnel from the side that believes it is still up to solve the immediate problem.
An investigation as to why the tunnel only went down from one side is recommended. It could be
that
DPD
and/or
Keep-Alive
is only used on one side. Another possible cause could be that even
though it has received a
DELETE
packet, it has not deleted/removed the tunnel.
4.
Payload_Malformed
This problem is very similar to the
Incorrect pre-shared key
problem described above. A possible
reason is that the PSK is of the wrong TYPE on either side (Passphrase or Hex key).
Verify that you are using the same type on both sides of the IPsec tunnel. If one side is using Hex
and the other Passphrase, this is most likely the error message that you will receive.
5.
No public key found
This is a very common error message when dealing with tunnels that use certificates for
authentication.
Troubleshooting this error message can be very difficult as the possible cause of the problem can be
quite extensive. Also it is very important to keep in mind that when dealing with certificates you
may need to combine the
ikesnoop
logs with normal logs as
ikesnoop
does not give that much
information about certificates, while normal logs can provide important clues as to what the problem
could be. A good suggestion before you start to troubleshoot certificate based tunnels is to first
configure it as a PSK tunnel and then verify that it can successfully establish, then move on to using
Certificates. (Unless the configuration type prohibits that).
The possible causes are as follows:
The certificate on either side is not signed by the same CA server.
The certificate's validity time has expired or it has not yet started to be valid. The latter can
happen if the clock is set incorrectly on either the CA server or the NetDefend Firewall or they
are in different time zones.
The NetDefend Firewall is unable to reach the
Certificate Revocation List
(CRL) on the CA
server in order to verify if the certificate is valid or not. Double-check that the CRL path is valid
in the certificate's properties. (Using the CRL feature could be turned off.) Make sure also that
there is a DNS client configured in NetDefendOS in order for it to be able to correctly resolve
the path to the CRL.
Note: L2TP with Microsoft Vista
With L2TP, Microsoft Vista tries by default to contact and download the CRL list,
while Microsoft XP does not. This option can be turned off in Vista.
9.7.5. Specific Error Messages
Chapter 9. VPN
441