Supporting Juniper and other types of SSL VPN

[David Woodhouse]

On Sun, 2015-01-04 at 11:05 +0100, Nikos Mavrogiannopoulos wrote:
> I think the reason we have multiple SSL VPNs is because there is no
> documented protocol for it, which works well. Once there is a documented
> protocol there will be very little incentive for each company to
> reinvent the wheel and define one. 

I wish that were true, but I suspect it isn't. While *we* would love the
VPN protocol to be commoditised, the companies selling VPN solutions
prefer to tie people in. Cisco really threw their toys out of the pram
when OpenConnect came along, and still don't support the servers
properly when OpenConnect is being used.

We see it even with the bug we're looking at right now with the ASA
dropping out-of-order DTLS packets. We know that the DTLS packets are
well-formed, and when received in sequence order the ASA will decrypt
them happily and pass them on. But when the same packets are reordered
in transit over the public Internet, as is wont to happen, the ASA drops
the lower-sequence-numbered packet that arrives later.

I can imagine *no* possible way in which the *client* can be responsible
for this behaviour, and still they are demanding that we reproduce it
with their crappy client before they look at it.

I really don't think we're going to get much buy-in to a standardised
protocol and commoditised clients. It's just not in their mindset.

Hell, these are the people who produced their own client even for IPSec.

> I think it is better in the long
> term, and more reasonable, to work towards a standardized protocol,
> rather than spending resources in reverse engineering and implementing
> every protocol out there.

Please be careful here. We really try to avoid reverse engineering the
clients, or using that term. Some of the licences explicitly prohibit
reverse engineering. It's one of the things Cisco were whining about
when OpenConnect was first created.

Thankfully, with a protocol based on HTTPS it's fairly trivial just to
look at the traffic on the wire, without prodding too hard at the client
itself. So reverse engineering hasn't been necessary.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150104/f0a61b57/attachment.bin>