New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 767549 link

Starred by 8 users

Issue metadata

Status: Archived
Owner:
Last visit > 30 days ago
Closed: Dec 13
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug


Show other hotlists

Hotlists containing this issue:
Chrome-Bug-Cleanup


Sign in to add a comment

Draytek L2TP/IPsec interop problem

Project Member Reported by cernekee@chromium.org, Sep 21 2017

Issue description

This problem came up in  bug 707139  around c#74.  It is separate from the L2TP/IPsec problems that were fixed in that bug, and (unlike the other issues in 707139) it is still being reported against the latest Chrome OS builds.  As Draytek support is now involved, we will move the discussion to a new "clean" ticket so they do not need to read through a long thread to get up to speed.

When a Chrome OS strongSwan client attempts to negotiate IPsec phase 2 with a Draytek VPN, the Draytek side sends a DELETE message back to the client:

2017-09-03T23:37:24.620150+01:00 INFO charon[11874]: 12[ENC] generating QUICK_MODE request 1215737414 [ HASH SA No ID ID NAT-OA NAT-OA ]
2017-09-03T23:37:24.620535+01:00 INFO charon[11874]: 12[NET] sending packet: from 192.168.0.22[4500] to VPN_IP[4500] (348 bytes)
2017-09-03T23:37:24.651160+01:00 INFO charon[11874]: 13[NET] received packet: from VPN_IP[4500] to 192.168.0.22[4500] (92 bytes)
2017-09-03T23:37:24.651408+01:00 INFO charon[11874]: 13[ENC] parsed INFORMATIONAL_V1 request 1128613447 [ HASH D ]
2017-09-03T23:37:24.651504+01:00 INFO charon[11874]: 13[IKE] received DELETE for IKE_SA managed[1]

This causes the Chrome OS client to immediately start over and retry Phase 1.  On the Draytek side this looks like:

 Time	                 Message
 2017-09-19 14:54:10	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:10	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:10	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:10	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:10	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:09	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:09	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:09	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:09	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:08	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 NAT-Traversal: Using RFC 3947, peer is NATed
 2017-09-19 14:54:08	 Matching General Setup key for dynamic ip client...
 2017-09-19 14:54:08	 Responding to Main Mode from 86.22.163.128
 2017-09-19 14:54:08	 sent MR3, ISAKMP SA established with 86.22.163.128. In/Out Index: 34/0

This is a Draytek Vigor 2850vn Log (in Reverse Chroological Order) From Chromebook VPN Connection Attempt (which fails after 10 seconds)


Draytek owners in the other thread have not been successful in enabling verbose debugging on the Draytek, so it is unclear why the phase 2 negotiation is failing.  We would like to determine the root cause for this failure in order to determine which of the following cases is true:

a) Chrome OS client is sending a valid request, but Draytek is not handling it correctly.

b) Chrome OS client is sending an invalid request and should be fixed so that Draytek no longer sends the DELETE response.

c) The two sides are simply using incompatible IPsec parameters (which may or may not have an easy, side-effect-free fix).

 

Comment 1 by tstoma...@gmail.com, Sep 22 2017

Hi Kevin,

Things had been suspiciously quiet from Draytek support, since I opened the case with them about this and which was given the case reference #DQ377476.  I just spoke with the support analyst who was assigned to the case and he explained to me that the issue has already been escalated to their engineering department, meaning there is little more he can do tpprogress the case.  He confirmed that he brought their engineers' attention to the previous case on this site and the fact that you had offered to collaborate with them to work towards resolving this.  He also pointed to me out that he could not force them to contact you.  I notified him of this new case that has been assigned to the issue and he agreed to notify their engineers of this development.  Let me know if no-one bothers to make contact with you within the next week or so and I will attempt to chase up what is going on.

Kind regards,

Steve

Hi,

Draytek's supportteam in the Netherlands are testing this now. I don't have a ticketnumber but they have setup a VPN-server and asked my to connect to it. After I have done that they noticed that the Chromebook issued an 'ICMP unreachable' packet. They also noticed a 'Xauth authentication' which they questioned.

On their request I have create a Wireshark capture of a failed VPN-connection (that was a bit difficult to set up...). You can see it in the attachment. 

Besides the 'remote' test to their Draytek router I also included a capture of an connection attempt to my own local Draytek router. This is LAN-only, no Internet, no NAT. For that failure I saved both the Wireshark capture and the Draytek log.

For further testing I requested Draytek to contact cernekee@chromium.org.

If I have any news I will let you know over here. Thanks for all support.
Chromebook to Draytek VPN problem WireShark captures.zip
105 KB Download

Comment 3 by tstoma...@gmail.com, Sep 23 2017

Hi Robert,

I'm really grateful for your on-going efforts with this.  I read through your documentation too and was impressed with the configuration you concocted to get the Wireshark capture!  If you or Draytek Netherlands want to double check if the behaviour is identical using a Draytek Vigor 2850vn, let me know and I will do whatever I can to assist.

Kind regards,

Steve

Comment 4 by tstoma...@gmail.com, Sep 25 2017

Hi Kevin (cernekee@chromium.org),

The support analyst at Draytek has emailed me to let me know that his engineers want to see what happens when my Chromebook attempts to connect to one of their Draytek 2960's, using a pre shared key configuraiton.  They have set up a VPN endpoint with an IP address, user ID and password and PSK for me to use.

I'm just wondering, is there some sort of system or application log I can easily enable and export from my Chromebook, so I can forward the info to Draytek and enable them to compare it with the VPN endpoint logs at their end?

Kind regards,

Steve
You can look for messages from charon in file:///var/log/net.log

Comment 6 by tstoma...@gmail.com, Sep 26 2017

Hi,

A quick update, for those who may be interested as to what has been going on with this.  Yesterday, by the request of Draytek Engineering, I performed a VPN connection test from my Chromebook to a Draytek router that was provided out on the web by the Draytek engineers.  Somewhat predictably, the connection attempt failed, but the error message was different to the 'received DELETE for IKE_SA managed' problem that was previously witnessed. On this occasion, the Chrome OS Net log reported a '(15) error notify'. Using relevant documentation, Kevin has explained this translates into:

3.15 BAD-PROPOSAL-SYNTAX

   The BAD-PROPOSAL-SYNTAX error message may be used to communicate that
   a received proposal is improperly formed. This message may be
   precipitated by the following events (among others):

     o a reserved field in a proposal payload does not
       contain zero (0)
     o a reserved field in a transform payload does not
       contain zero (0)
     o responder returns SA payload containing multiple proposals
     o responder returns multiple (or no) transforms
     o initiator attempts to negotiate multiple quick mode SAs
       but responder only answers to one of them.

The ball is currently in Draytek Support/Engineering's court.

Email between me and Kevin Cernekee is being cc'd to Draytek Support and email between me and Draytek Support is being cc'd to Kevin Cernekee.  Although it would probably be better if there was direct communication between Kevin and Draytek, as far as I am aware Draytek Engineering have not yet approached Kevin directly.  We will consequently continue as is, for the time being.

Keep you posted.

Kind regards,

Steve
Thanks for the update Steve.
Robert
Thanks for the update. Any more news?
I asked Draytek Netherlands if there is any progress, they are still working on it. 
Kevin (cernekee@chromium.org), were you able to have a look at the Wireshark capture?
Regarding the wireshark trace:

1) Most of the IKE exchange is encrypted, so it is necessary to tell at least one side to log the ephemeral keys so that they can be entered into wireshark: https://ask.wireshark.org/questions/12019/how-can-i-decrypt-ikev1-andor-esp-packets

(Currently this takes a bit of manual effort on the Chrome OS side.  I'll see if it can be enabled from crosh, and if not, add it.)

2) Since we know what error the Draytek device is sending back to the Chromebook (because it is recorded in net.log), the trace isn't very useful to me.  It is more important to find out what decision process the Draytek is following when it decides to reject the connection.  At that point we can zero in on that decision and figure out whether the Chromebook is sending something out of spec, the Draytek is rejecting something in-spec, or they are merely using incompatible settings.
hi, same problem here.
trying to connectto a Vigor 2820.
no issues from the android built-in VPN client from my phone: VPN works via PPTP and via L2TP psk too.
No ways from chromebook.
Is there any news about this issue?

"It is more important to find out what decision process the Draytek is following when it decides to reject the connection." (comment 10)
Does this mean the Chromium team is not looking into this any further at the moment, since we can't get that information?
It's been several months now. It would be great to have at least confirm this to be a bug in one of the products, or not. 

As I have understand from Draytek they are in contact with the Chromium-team. Draytek somehow doesn't have any Chromebook available for testing. 

It should not be that hard for the Chromium-team to do a test with a router configured by Draytek, is it? They have asked me several times to test my Chromebook with their router. Last week Draytek asked me on behalf of someone from the Chromium-team for my Chromebook's network-logs. I think it would be much more efficient if the Chromium team themselves try to establish a VPN setup by Draytek and both have a look at what goes wrong (or not). 

After months we still even don't know if we (end-users) do something wrong or that there is a real bug. I don't know what to say to our customers. I think this problem will get a higher priority if we could confirm it's a bug (or not).
Any update on this L2TP/IPSec issue?
I've just ran into the same issue on trialling Chromebook, cannot get VPN connected from Chromebook to Draytek 2952
Works fine on Win10 device
Hi,

I raised a ticket with Draytek about this issue and, theoretically, the Draytek engineers/developers were supposed to be collaborating with Kevin Cernekee (the relevant Chrome OS network developer) to sort this out.  I don't get the impression, however, that Draytek have put too much effort into doing anything about this since.

As for whether on not there is a bug in either the Drayek VPN server or Chrome OS, I think it was more just a question of a loss of compatiblity.  As I understand it, the Chrome OS was updated to fall more closely into line with the current VPN handshaking protocols/negotiation standards. Draytek have evidently fallen behind the times and whilst certain VPN clients, such as Microsoft's, still accomodate older VPN servers such as Draytek's, the Chrome OS moved on to the point where it ceased to work with Draytek routers.  Draytek also appear to have been dragging their heels, as far as having any interest in catching up up with the current standards.

HOWEVER, the light at the end of this tunnel suddenly became much brighter for me today in the form of a viable workaround, certainly in my case, that is. On my particular chromebook, Android apps have been supported in the 'Stable Channel' for some time.  Draytek offer an Android based VPN client, called "Smart VPN', but although this VPN client used to connect sucessfully from my Chromebook to my Draytek Vigot 2850vn, neither the Chrome browser nor any other apps installed on the Chromebook could access the connection.  The issue that prevented the Draytek Smart VPN from working would appear to have now been fixed and is available in the current release of the stable channel!

Here is the relevant link in the Chrome OS Bug Site:

https://bugs.chromium.org/p/chromium/issues/detail?id=696865

The new feature that needs to be enabled is accessed on your Chromebook via:

chrome://flags#arc-vpn

Just set the feature to 'Enabled'

After setting the value to 'Enabled' the Draytek Smart VPN App for Android would appear to work for both the Chromebook's browser and any other apps installed (e.g. the Xtralogix RDP Client, which I rely upon heavily to access my Windows PC remotely, from my Chromebook).

Whilst, from a purist's perspective, Draytek really ought to bring there VPN server up-to-date, for my purposes I just needed something to work.  This does, at least it works for me!

Thank you Kevin Cernekee, for your efforts on both this case and the one which has ultimately now provided me with a viable workaround.

Kind regards,

Steve
> chrome://flags#arc-vpn

FYI, this flag will be enabled by default when M64 rolls out to stable channel this month.

Still happy to work with Draytek on troubleshooting the interop problem if they can take a look at what is happening on the router side...
Hi Kevin,

Yeah, I'd realised that it was defaulted on in M64, but hadn't appreciated that version would be rolled out to the stable channel this month.  Thanks for the info.  

I don't think I'm going to mention this workaround of now being able to use the Draytek Smart VPN Android app on the Chromebook.  On the basis that they've been dragging their heels already, in terms of collaborating with you so you can help them solve their problem, they are certainly not going to suddenly start making an effort if they find out there is now a way around the problem!

Thanks again for all your efforts on this issue and for fixing the problem with third party Android VPN clients on thr Chromebook.  It was previously a real bind for me, having to fire up a VPN connection on my phone, just to open up the necessary ports on my router, so I could subsequently RDP into my Windows machine from my Chromebook!

I will prod Draytek again about what is going on regarding their open case on this topic and once again request that their engineers/developers contact you.  I can't believe they aren't biting you arm off for the assistance you've offered them!

Kind regards,

Steve
Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!
Status: Archived (was: ExternalDependency)
Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.

Sign in to add a comment