OpenConnect checks for a specific 3-byte response after sending the Juniper/NC "hostname packet" (http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/oncp.c#l685): 01 00 00 I'm working with a Juniper VPN which returns a different 3-byte response (sometimes but not always), before proceeding normally. I added an extra dump_buf_hex to print it: $ openconnect --prot=nc -vvvv ... > 0000: 18 00 00 04 00 00 00 0b 00 64 6c 65 6e 73 6b 69 > 0010: 2d 31 32 33 bb 01 00 00 00 00 Read 3 bytes of SSL record < 0000: d2 01 00 Read 467 bytes of SSL record Here's what I think is going on: I believe this server is concatenating the 3-byte response packet together with the longer IP-configuration packet that follows (0x1d2 == 466, which suggests that it's encoding the size of the following packet). I do not see any particular distinguishing features of this server, other than that it returns the following header in the hostname packet response, indicating a very old Network Connect version: NCP-Version: 2 By the way, this server *also* has the bug reported by Nikolay Martynov wherein it sends packets larger than the expected MTU. My guess is that it will be safe to simply ignore the first two bytes of the hostname response packet in all cases, and proceed normally. I will submit a patch to do just that. -Dan
