Problems establishing tunnels between Clavister SGW and Draytek firewalls

Frequently Asked Questions
Post Reply
Rob
Posts: 5
Joined: 11 Jan 2016, 10:52

Problems establishing tunnels between Clavister SGW and Draytek firewalls

Post by Rob » 23 Feb 2017, 12:39

This FAQ applies to:
  • Clavister CorePlus / cOS Core all versions / Draytek firewalls
Question:

I'm unable to establish a tunnel between Clavister and Draytek, and seeing "incorrect pre-shared key" log events, even though I'm sure correct PSK is used and correct tunnel is triggering

Answer:

We have noticed some behaviour when connecting a Clavister SGW to Draytek firewalls, in which Draytek has issues establishing tunnels during IKE Phase 1 and specifically agreeing on PSK during key exchange.

The issue seems to be with how Draytek are handling IPsec lifetimes, since even with default values of 28800 for Phase 1, Draytek is unable to complete key exchange. When Draytek devices are in use and tunnels aren't establishing, even though it's known that the PSK and IKE/IPsec proposals match, you'll likely see the following in logs when troubleshooting:

When running ike -snoop from cOS Core, there will typically be messages such as the following:

Code: Select all

IkeSnoop: core:203.0.113.20:4500 <- WAN:203.0.113.30:13914
IkeSnoop: core:203.0.113.20:4500 -> WAN:203.0.113.30:58754
ISAKMP Version   : 1.0
Exchange type    : Informational
Initiator cookie : 0x47dc99c91d0fa0c0
Responder cookie : 0x3933a4ef6ef75573
Flags            :
Message ID       : 0x8ca7095d
Length           : 181 bytes
# payloads       : 1
Payloads:
  N (Notification)
    Payload data length : 149 bytes
    Protocol ID  : ISAKMP
    Notification : Invalid payload type
    Notification data:
      Notify message version: 1
      Offending payload type: Unknown payload type
      Error text: "Incorrect pre-shared key (Invalid next payload value)"
      Offending message ID: 0x00000000

IkeSnoop: core:203.0.113.20:4500 <- WAN:203.0.113.30:13914
IkeSnoop: core:203.0.113.20:4500 <- WAN:203.0.113.30:13914
IkeSnoop: IKE packet belongs to unknown IKE SA
When looking at syslogs from Draytek, output may look like the following:

Code: Select all

[IPSEC/IKE][L2L][2:RFAG-OUT][@203.0.113.20] state transition fail: STATE_MAIN_R0
 connection: 829e5734 is dial-out and NOT for dynamic client; in_index=0, out_index=-2. U can try to reduce phase1 lifetime...
 connection: 829e5734 is dial-out and NOT for dynamic client; in_index=0, out_index=-2. U can try to reduce phase1 lifetime...
 connection: 829e5734 is dial-out and NOT for dynamic client; in_index=0, out_index=-2. U can try to reduce phase1 lifetime...
 Find Phase1 proposal: SHA2_256
 connection: 829e5734 is dial-out and NOT for dynamic client; in_index=0, out_index=-2. U can try to reduce phase1 lifetime...
 Responding to Main Mode from 203.0.113.20
[IPSEC/IKE][L2L][2:RFAG-OUT][@203.0.113.20] state transition fail: STATE_MAIN_R0
 connection: 829e5734 is dial-out and NOT for dynamic client; in_index=0, out_index=-2. U can try to reduce phase1 lifetime...
 connection: 829e5734 is dial-out and NOT for dynamic client; in_index=0, out_index=-2. U can try to reduce phase1 lifetime...
 connection: 829e5734 is dial-out and NOT for dynamic client; in_index=0, out_index=-2. U can try to reduce phase1 lifetime..
Here Draytek's own logging gives a clue with "U can try to reduce phase1 lifetime...".


When inspecting Draytek's management interface, depending on the firmware version, log output may look like this:
Draytek Final.png
Draytek Final.png (243.99 KiB) Viewed 1896 times
To solve this problem, try lowering the IKE Phase 1 lifetime from the default value of 28800. Keep in mind that as Draytek can be quite sensitive with IPsec/IKE lifetime values, both must match between cOS and Draytek. In tests, we've seen 15000 work without issues, although Draytek may still output log events similar to what's listed above. Even so, tunnels come up and traffic is allowed to pass.

Post Reply