Weird IPsec errors when trying L2TP/IPsec from Draytek

pe1chl · Fri Dec 15, 2017 9:41 pm

After a user of our network complained they cannot get a connection whatever they try, using a Draytek router to setup L2TP/IPsec, I decided to get my old Draytek router out of the junkbox and give it a try.
On the MikroTik router I have setup L2TP/IPsec service with basically all default parameters.
Lots of users are connected using L2TP client with IPsec secret (and username/pw) from MikroTik routers, and I know from experience that the same setup works from Android etc.

So I installed the latest firmware on my Draytek 2860n+ and setup the "LAN2LAN VPN" with L2TP/IPsec. At defaults it does not work at all, but after setting Advanced settings to use AES128_SHA1_G2 for phase1 and AES128_SHA1 for phase2 it at least establishes phase1.
On the MikroTik side a phase2 SA is accepted (according to debug log) and the session gets stuck in "msg1 sent" state, then proceeding to log "the packet is retransmitted by..." messages.

In the Draytek log, the following is logged (spelling-corrected):

[IPSEC/IKE][L2L][profilename][remote IP] malformed payload: Parse error: byte 7 of ISAKMP NAT-OA Payload must be zero, but is not

Interestingly, Google finds some reports of such an error message in completely different environments (no MikroTik or Draytek involved, but with Strongswan software).
Some of them are quite old, but I have not found a clue what is causing the problem and on which side it is....
(i.e. is the byte not zeroed on the sending end, MikroTik in this case, and is the receiving end rightly complaining about it, or should the receiving end just ignore this nonzero byte? could it be caused by some setup error?)

Anyone with experience with this matter?

GeorgeHibberd · Wed Jan 31, 2018 12:56 am

Hi, Im having the exact same issue, with a Mikrotik and DrayTek did you ever find a solution?

GeorgeHibberd · Wed Jan 31, 2018 2:46 pm

Hi,

Im having the exact same issue with it not brining up Phase 2, the tunnel work fine when not using encryption, i have setup using L2TP from a Phone + Laptop and having no issue getting the encryption running,

did you ever find a solution?

Cheers

sindy · Sat Feb 03, 2018 11:49 pm

If you can do without L2TP and use pure IPsec with policies, that way is known to work with both the Mikrotik and the Draytek on public IP. The Drayteks I've had to do with would not support NAT-T.

pe1chl · Sat Feb 03, 2018 11:58 pm

No I have not resolved it yet. I think it will not work with NAT-T and I can only conveniently test it with a Draytek router behind NAT.
Draytek does support it but apparently there is a bug on one of the sides.
I cannot use plain IPsec tunnel in this case because the remote is on a dynamic address.

pe1chl · Sat Jul 14, 2018 2:47 pm

I have updated the Draytek firmware to 3.8.9.1 and RouterOS to 6.42.5 but situation is still the same.

byte 7 of ISAKMP NAT-OA Payload must be zero, but is not

Is this something that could be fixed by MikroTik?

sindy · Sat Jul 14, 2018 3:15 pm

Is that a message from Draytek's log or Mikrotik's?

pe1chl · Sat Jul 14, 2018 4:02 pm

It is in the Draytek log. It only occurs when operating over NAT.
The MikroTik believes everything is fine and logs "the packet is retransmitted by x.x.x.x[4500]".
I now managed to get a Draytek connected to a public IP and now I can setup a working L2TP/IPsec connection to the MikroTik!
But I think Draytek would normally support NAT-T, at least it is trying UDP port 4500 etc. So there is some incompatibility.

sindy · Sat Jul 14, 2018 6:53 pm

From RFC 3947:

The format of the NAT-OA packet is

         1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
       +---------------+---------------+---------------+---------------+
       | Next Payload  | RESERVED      | Payload length                |
       +---------------+---------------+---------------+---------------+
       | ID Type       | RESERVED      | RESERVED                      |
       +---------------+---------------+---------------+---------------+
       |           IPv4 (4 octets) or IPv6 address (16 octets)         |
       +---------------+---------------+---------------+---------------+

The payload type for the NAT original address payload is 21.

The ID type is defined in the [RFC2407]. Only ID_IPV4_ADDR and ID_IPV6_ADDR types are allowed. The two reserved fields after the ID Type must be zero.

So I've taken the ipsec log at the Mikrotik ipsec-l2tp client behind a NAT (because the NAT-OA payload is sent already in the encrypted stage of Phase 1 and because the log shows decrypted contents only for received packets), and the Mikrotik server sends the following:

 1500000c 011106a5 c0a80a58
 1500000c 01001194 0a000005
 0000000c 01001194 c0a80a58

0x15 = payload type, 21
0x00 = reserved, correct
0x000c = record length, correct

0x01 = IPv4
0x001194 is clearly not 0x000000. However, RFC2407, to which RFC3947 refers, assumes another payload format which contains a reference to ID type, which is the Identification Payload:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !  Next Payload !   RESERVED    !        Payload Length         !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !   ID Type     !  Protocol ID  !             Port              !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Identification Data                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And if interpreting the 0x1106a5 this way,
0x0 = IPv6 HOPOPT, probably not relevant
0x1194 = 4500 = the alternative (NAT-T) ISAKMP port

So to me it is a clear bug at Mikrotik side where guys reuse the already prepared payload contents (as in both cases the IP address occupies the last 4 bytes of the payload) but forget to "and" the row with ID type before sending with 0xFF000000.

The only drawback is that I've done the test with 6.42.1 running on the server but I guess that won't be a big issue when you'll be sending this to support@mikrotik.com

pe1chl · Sat Jul 14, 2018 7:39 pm

Thanks for debugging it

So it indeed something that should be fixed on the MikroTik side to be standards compliant.
Apparently the used IPsec code does not check this condition.
Maybe it is responsible for other L2TP/IPsec trouble as well...
From my googling it looks like Strongswan at some time had this problem and has been fixed, but maybe MikroTik use an old version?
I have alerted support to this topic.

sindy · Sat Jul 14, 2018 7:57 pm

but maybe MikroTik use an old version?

I would rather say "is based on an old version" given how quickly gents there have reacted on some claims I had recently, but I'm afraid the only next step which makes sense is to send that to support

You're affected, you send it - all the Drayteks I've ever met were remote so I'd be unable to validate the solution once provided.

pe1chl · Sat Jul 14, 2018 8:01 pm

I have alerted support to this topic. Let's see what happens...
I am in a similar situation, I am only debugging this for some people who want to connect to my server and I pulled my
old Draytek out of the junkbox to do it. When behind another (MikroTik) router as NAT it does not work, but then I thought
about a 4G SIM and USB stick I have that provides a direct IP address and with that in the Draytek router it is possible to
connect (without NAT-T). So the other parts of IPsec and L2TP do interwork correctly.

sindy · Sun Jul 15, 2018 10:27 pm

Even the Wireshark ISAKMP dissector doesn't bother to check that the contents of the RESERVED bytes in NAT-OA payload is 0x00 0x0000

Use "Import from Hex Dump" of the following data, with UDP dummy header with source port 500:

0000 cf 79 93 70 33 48 f6 07 b9 3a 53 64 df f8 e5 c1
0010 08 10 20 00 d0 7a f8 56 00 00 00 bc 01 00 00 18
0020 bb dc 22 3a 45 e4 40 a6 08 cd c9 f9 f7 63 30 d8
0030 7d d3 4e e3 0a 00 00 34 00 00 00 01 00 00 00 01
0040 00 00 00 28 01 03 04 01 05 13 62 b2 00 00 00 1c
0050 03 0c 00 00 80 01 00 01 80 02 07 08 80 04 00 04
0060 80 06 01 00 80 05 00 02 05 00 00 1c d6 3a 6d 7e
0070 34 48 22 07 48 54 d9 1a cd 39 39 fc 5b 8f 2c ee
0080 06 9b bc a6 05 00 00 0c 01 11 06 a5 c0 a8 05 ad
0090 15 00 00 0c 01 11 06 a5 c0 a8 0a 58 15 00 00 0c
00a0 01 00 11 94 0a 00 00 05 00 00 00 0c 01 00 11 94
00b0 c0 a8 0a 58 61 b3 4e 5d 7b 4c 7d 07

sindy · Mon Jul 16, 2018 9:45 am

Thinking about it further, it may have been a clever idea how to tell the remote peer on which port I am listening, making use of an apparently unused space in an existing parameter, and the Draytek implementation throws pitchfork into it by checking for the zeroes.

pe1chl · Mon Jul 16, 2018 10:48 am

Ticket#2018071422001752 has been created for this issue.
Of course there is another issue with this: the MikroTik implementation is unable to serve more than one L2TP/IPsec over NAT client
behind the same remote IP. This is a regularly recurring complaint, mainly when people try to setup a VPN from several mobile
devices connecting via the same mobile provider who uses CGNAT. I have also found that the standard server configuration which
sets IPsec to "port strict" mode does not work correctly when there are 2 levels of NAT in the connection. Setting up a custom IPsec
peer with "port override" solves that.
Maybe it is related and/or a solution for this issue could solve that as well?

sindy · Mon Jul 16, 2018 11:01 am

The non-standard population of the NAT-OA ISAKMP payload has nothing to do with the "multiple L2TP/IPsec clients behind the same NAT" problem.

The root cause of that problem and a working solution are described here.

pe1chl · Mon Jul 16, 2018 11:13 am

Ok, thanks. I thought the fields in the NAT-OA packet maybe could be part of an incomplete solution to work around that problem.

pe1chl · Wed Aug 15, 2018 2:15 pm

The problem has been resolved in version 6.43rc56
So when a 6.43 stable version appears we will install that and be able to use this protocol from Draytek routers.

Weird IPsec errors when trying L2TP/IPsec from Draytek [SOLVED]

Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek

Re: Weird IPsec errors when trying L2TP/IPsec from Draytek [SOLVED]

Who is online