Mailing List Archive: vpnc: devel

Disconnects after 10 seconds

Index | Next | Previous | View Threaded

dichoso at gmail

Nov 3, 2008, 6:44 PM

Post #1 of 15 (3222 views)
Permalink

Disconnects after 10 seconds

Hi,

I have same issue of ten second lasting connections, it works ok until
something happens and connection got closed. This has been happening for a
while and I can tell there are lot of people with same issue, my thinking is
at some point concentrator validates client version and if it doesn't match
allowed clients it closes connection with client.

this is my debug 3 session at the moment connection ends:

sending ESP packet (after ah):
45008800 b2480000 40322a21 c0a83d02 97c180fd 89851d2b 0000000f 1d391647
8d8cb869 87be87e2 33df0262 d1959304 35d68025 cce1de40 04de8e3f 8443d9c8
ef2fc88e 30f58b84 8ac8a6f6 aa4b0da5 74098149 f3c300e8 77311670 e78e9b62
3a3ef068 d7ffc528 21f4c15f 46d6e11f 34adaade 9f591274 bfa1f988 4d2b38a7
a0f64804 aace517f
lifetime status: 14 of 28800 seconds used, 0|1 of 0 kbytes used
received something on ike fd..
got late ike paket: 68 bytes
BEGIN_PARSE
Recieved Packet Len: 68
i_cookie: 2b83f0b0 e1d77173
r_cookie: abd037f3 9342d8c9
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: b520bdbb
len: 00000044

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
7de19752 c067f892 4b59a6ae 4357a6a6 f3d86200
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0010
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
d.spi_length: 04
d.num_spi: 0001
d.spi: 89851d2b
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
PARSE_OK
hashlen: 20
u.hash.length: 20
expected_hash:
7de19752 c067f892 4b59a6ae 4357a6a6 f3d86200
h->u.hash.data:
7de19752 c067f892 4b59a6ae 4357a6a6 f3d86200
got non isakmp-delete, ignoring...
lifetime status: 14 of 28800 seconds used, 0|1 of 0 kbytes used
received something on ike fd..
got late ike paket: 84 bytes
BEGIN_PARSE
Recieved Packet Len: 84
i_cookie: 2b83f0b0 e1d77173
r_cookie: abd037f3 9342d8c9
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: 368ed90f
len: 00000054

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
1598fabd 48ae0e8f 3eaeb296 207fa9fc 189cb0ba
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 001c
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 01 (ISAKMP_IPSEC_PROTO_ISAKMP)
d.spi_length: 10
d.num_spi: 0001
d.spi: 2b83f0b0 e1d77173 abd037f3 9342d8c9
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
extra data: 00000000
PARSE_OK
hashlen: 20
u.hash.length: 20
expected_hash:
1598fabd 48ae0e8f 3eaeb296 207fa9fc 189cb0ba
h->u.hash.data:
1598fabd 48ae0e8f 3eaeb296 207fa9fc 189cb0ba
got isakmp-delete, terminating...

S7.10 send termination message
[2008-11-04 00:26:41]
size = 44, blksz = 8, padding = 4

sending: ========================>
BEGIN_PARSE
Recieved Packet Len: 76
i_cookie: 2b83f0b0 e1d77173
r_cookie: abd037f3 9342d8c9
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: 92000000
len: 0000004c

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
0f937afe 7090127a f7c240d0 539742c1 58bc90d9
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0014
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
d.spi_length: 04
d.num_spi: 0002
d.spi: 7a7be4ff
d.spi: 89851d2b
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
extra data: 00000000
PARSE_OK
size = 52, blksz = 8, padding = 4

sending: ========================>
BEGIN_PARSE
Recieved Packet Len: 84
i_cookie: 2b83f0b0 e1d77173
r_cookie: abd037f3 9342d8c9
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: b6000000
len: 00000054

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
431f604d 5427e59f 68cfe368 c6720cd5 983878be
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 001c
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 01 (ISAKMP_IPSEC_PROTO_ISAKMP)
d.spi_length: 10
d.num_spi: 0001
d.spi: 2b83f0b0 e1d77173 abd037f3 9342d8c9
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
extra data: 00000000
PARSE_OK

jmvpnc at loplof

Nov 4, 2008, 2:07 PM

Post #2 of 15 (3111 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

On Tue, Nov 04, 2008 at 12:44:57AM -0200, Dichi wrote:
> I have same issue of ten second lasting connections, it works ok until
> something happens and connection got closed. This has been happening for a
> while and I can tell there are lot of people with same issue, my thinking is
> at some point concentrator validates client version and if it doesn't match
> allowed clients it closes connection with client.
>
> this is my debug 3 session at the moment connection ends:
...

Until a few minutes ago, vpnc printed some messages to syslog but not to
the terminal. So if you could rebuild vpnc from current svn HEAD and then
rerun the trace, capturing stdout and stderr, that would probably help.

Ciao
Joerg

--
Joerg Mayer <jmayer [at] loplof>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

dichoso at gmail

Nov 5, 2008, 5:48 PM

Post #3 of 15 (3125 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Here is the output of same test with vpnc 358, i got same results:

sending ESP packet (after ah):
45008800 3c4e0000 4032a019 c0a83d03 97c180fd 5c399443 0000000d 5376273f
ba0d4121 f511988f e2a79e60 2d0ede48 a2f1b908 84b160f2 a7e240d3 b12ffb5c
31641fff 07e61ca4 4bd9b6c1 f470684f 29070ab1 16e76b67 d001b4f3 149d747f
1212528a a82a87ed 226f568e 5d955b4d 6761827c a8623994 9c67b10f 54227c5c
8c28868b 87e79b0a
lifetime status: 14 of 28800 seconds used, 0|1 of 0 kbytes used
received something on ike fd..
got late ike paket: 68 bytes
BEGIN_PARSE
Recieved Packet Len: 68
i_cookie: fcdc4ce4 8fc828d3
r_cookie: b868ba9f 55edf58a
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: c575dd49
len: 00000044

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
9e8414c4 c0df1e81 94219deb 98152fdb 13843359
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0010
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
d.spi_length: 04
d.num_spi: 0001
d.spi: 5c399443
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
PARSE_OK
hashlen: 20
u.hash.length: 20
expected_hash:
9e8414c4 c0df1e81 94219deb 98152fdb 13843359
h->u.hash.data:
9e8414c4 c0df1e81 94219deb 98152fdb 13843359
got non isakmp-delete, ignoring...
lifetime status: 14 of 28800 seconds used, 0|1 of 0 kbytes used
received something on ike fd..
got late ike paket: 84 bytes
BEGIN_PARSE
Recieved Packet Len: 84
i_cookie: fcdc4ce4 8fc828d3
r_cookie: b868ba9f 55edf58a
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: 6a924c70
len: 00000054

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
92508142 90cea938 037279f8 5b57d575 6cc72166
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 001c
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 01 (ISAKMP_IPSEC_PROTO_ISAKMP)
d.spi_length: 10
d.num_spi: 0001
d.spi: fcdc4ce4 8fc828d3 b868ba9f 55edf58a
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
extra data: 00000000
PARSE_OK
hashlen: 20
u.hash.length: 20
expected_hash:
92508142 90cea938 037279f8 5b57d575 6cc72166
h->u.hash.data:
92508142 90cea938 037279f8 5b57d575 6cc72166
got isakmp-delete, terminating...
vpnc[6600]: connection terminated by peer

S7.10 send termination message
[2008-11-05 23:45:22]
size = 44, blksz = 8, padding = 4

sending: ========================>
BEGIN_PARSE
Recieved Packet Len: 76
i_cookie: fcdc4ce4 8fc828d3
r_cookie: b868ba9f 55edf58a
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: 50000000
len: 0000004c

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
597f2e98 b623db5d c5df4856 14c37787 97fde03f
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 0014
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 03 (ISAKMP_IPSEC_PROTO_IPSEC_ESP)
d.spi_length: 04
d.num_spi: 0002
d.spi: 4ad26989
d.spi: 5c399443
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
extra data: 00000000
PARSE_OK
size = 52, blksz = 8, padding = 4

sending: ========================>
BEGIN_PARSE
Recieved Packet Len: 84
i_cookie: fcdc4ce4 8fc828d3
r_cookie: b868ba9f 55edf58a
payload: 08 (ISAKMP_PAYLOAD_HASH)
isakmp_version: 10
exchange_type: 05 (ISAKMP_EXCHANGE_INFORMATIONAL)
flags: 01
message_id: 7b000000
len: 00000054

PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)
next_type: 0c (ISAKMP_PAYLOAD_D)
length: 0018
ke.data:
7c98289d 067def79 20133282 db63bb94 8fc8e946
DONE PARSING PAYLOAD type: 08 (ISAKMP_PAYLOAD_HASH)

PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)
next_type: 00 (ISAKMP_PAYLOAD_NONE)
length: 001c
d.doi: 00000001 (ISAKMP_DOI_IPSEC)
d.protocol: 01 (ISAKMP_IPSEC_PROTO_ISAKMP)
d.spi_length: 10
d.num_spi: 0001
d.spi: fcdc4ce4 8fc828d3 b868ba9f 55edf58a
DONE PARSING PAYLOAD type: 0c (ISAKMP_PAYLOAD_D)

PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
extra data: 00000000
PARSE_OK

S8 close_tunnel
[2008-11-05 23:45:22]
sh: ./vpnc-script: not found

S9 cleanup
[2008-11-05 23:45:22]

On Tue, Nov 4, 2008 at 8:07 PM, Joerg Mayer <jmvpnc [at] loplof> wrote:

> On Tue, Nov 04, 2008 at 12:44:57AM -0200, Dichi wrote:
> > I have same issue of ten second lasting connections, it works ok until
> > something happens and connection got closed. This has been happening for
> a
> > while and I can tell there are lot of people with same issue, my thinking
> is
> > at some point concentrator validates client version and if it doesn't
> match
> > allowed clients it closes connection with client.
> >
> > this is my debug 3 session at the moment connection ends:
> ...
>
> Until a few minutes ago, vpnc printed some messages to syslog but not to
> the terminal. So if you could rebuild vpnc from current svn HEAD and then
> rerun the trace, capturing stdout and stderr, that would probably help.
>
> Ciao
> Joerg
>
> --
> Joerg Mayer <jmayer [at] loplof>
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/<http://www.unix-ag.uni-kl.de/%7Emassar/vpnc/>
>

borneo.antonio at gmail

Nov 8, 2008, 9:24 AM

Post #4 of 15 (3108 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Hi,
digging in the obscure data that Nortel client exchanges with server,
I have found some data that I hope could be interesting for this case.

The patch attached mainly uses some "undocumented" info to set DNS
default domain.
There is no official field for such info in ISAKMP, and also Cisco
uses its own "proprietary" field.
I'm using two Contivity servers, and each uses a different attribute
value for DNS domain.
I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
Please test, with --debug 3, if other fields are also used for such purpose.

The patch also identify and print 2 fields:
- ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
This is an alternate server IP, that can be used as backup
connection in case the server you are logged-in becomes unavailable.
Almost useless info. Nortel client does not seems using it too.
- ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
This could be interesting!
When I login with official client, I get a pop-up with a legal
disclaimer from my company
e.g. "don't use this connection if you are not authorized", or similar.
This text is exchanged through a standard qotd server placed beyond
Nortel concentrator.
The client receives the IP of qotd server inside this field, then
connects to it and get the string.

It could be that the concentator closes the connection if the client
does not read the qotd string.
I have nothing to prove this crazy behaviour. My connections never got
such problem.
To test it, you need to connect vpnc, get qotd server IP and connect
to its port 17
e.g. "telnet x.y.w.z 17"
The attached patch, if run with "--debug 1", prints the string
> QOTD server: run:
> telnet x.y.w.z 17
so you can immediately copy the telnet string and paste it in another terminal.
Good luck!

Best Regards,
Antonio Borneo

2008/11/4 Dichi <dichoso [at] gmail>:
> Hi,
>
> I have same issue of ten second lasting connections, it works ok until
> something happens and connection got closed. This has been happening for a
> while and I can tell there are lot of people with same issue, my thinking is
> at some point concentrator validates client version and if it doesn't match
> allowed clients it closes connection with client.

Attachments:

patch_attrib.txt (1.77 KB)

dichoso at gmail

Nov 8, 2008, 11:46 AM

Post #5 of 15 (3104 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Thanks, that helped

I think this reinforce my theory of "client string", look what QOTD
server gave me:

Connectivity to this environment
requires that you use a minimum version
V04_91 of the Nortel VPN client. Please
contact the Help Desk for assistance in
obtaining the latest version of the Nortel
VPN client.

Is there any way to decode what apani/nortel clients send as "client
version"???

Thanks,
Mariano

On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
> Hi,
> digging in the obscure data that Nortel client exchanges with server,
> I have found some data that I hope could be interesting for this case.
>
> The patch attached mainly uses some "undocumented" info to set DNS
> default domain.
> There is no official field for such info in ISAKMP, and also Cisco
> uses its own "proprietary" field.
> I'm using two Contivity servers, and each uses a different attribute
> value for DNS domain.
> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
> Please test, with --debug 3, if other fields are also used for such purpose.
>
> The patch also identify and print 2 fields:
> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
> This is an alternate server IP, that can be used as backup
> connection in case the server you are logged-in becomes unavailable.
> Almost useless info. Nortel client does not seems using it too.
> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
> This could be interesting!
> When I login with official client, I get a pop-up with a legal
> disclaimer from my company
> e.g. "don't use this connection if you are not authorized", or similar.
> This text is exchanged through a standard qotd server placed beyond
> Nortel concentrator.
> The client receives the IP of qotd server inside this field, then
> connects to it and get the string.
>
> It could be that the concentator closes the connection if the client
> does not read the qotd string.
> I have nothing to prove this crazy behaviour. My connections never got
> such problem.
> To test it, you need to connect vpnc, get qotd server IP and connect
> to its port 17
> e.g. "telnet x.y.w.z 17"
> The attached patch, if run with "--debug 1", prints the string
>> QOTD server: run:
>> telnet x.y.w.z 17
> so you can immediately copy the telnet string and paste it in another terminal.
> Good luck!
>
> Best Regards,
> Antonio Borneo
>
>
> 2008/11/4 Dichi <dichoso [at] gmail>:
>> Hi,
>>
>> I have same issue of ten second lasting connections, it works ok until
>> something happens and connection got closed. This has been happening for a
>> while and I can tell there are lot of people with same issue, my thinking is
>> at some point concentrator validates client version and if it doesn't match
>> allowed clients it closes connection with client.
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

borneo.antonio at gmail

Nov 8, 2008, 7:17 PM

Post #6 of 15 (3110 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Ciao Mariano,
it's really positive that you can connect with the qotd server; it
means the vpn tunnel is up and running.
Also, having your server replying with a useful message, push me to
better implement this qotd connection. I was already thinking this
should be implemented to skip any legal issue related with banner
disclaimer, but I considered it a low priority task; now I changed
mind.

I have to recover some old experiment I have done in the past.
I remember a situation in which the server ask for another
undocumented field, and client reply with a text string including OS
name and client version.
I skipped on purpose that situation, not mandatory for me, to avoid
sending such info.
At that time, I do not want to lie, by sending "fake" version and
claiming my vpnc is Nortel-something.
At the same time, I prefer not sending "vpnc version 0.5.1-352M". I
believe that a paranoid sysadmin could consider it as a cracker using
an "unofficial" and "unapproved" client, getting my account
immediately shut-down.

To solve your situation, I have to go back to my old work, and we have
to send an "accepted" string.

Best Regards,
Antonio Borneo

On Sun, Nov 9, 2008 at 3:46 AM, Dichi <dichoso [at] gmail> wrote:
> Thanks, that helped
>
> I think this reinforce my theory of "client string", look what QOTD
> server gave me:
>
> Connectivity to this environment
> requires that you use a minimum version
> V04_91 of the Nortel VPN client. Please
> contact the Help Desk for assistance in
> obtaining the latest version of the Nortel
> VPN client.
>
> Is there any way to decode what apani/nortel clients send as "client
> version"???
>
> Thanks,
> Mariano
>
> On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>> Hi,
>> digging in the obscure data that Nortel client exchanges with server,
>> I have found some data that I hope could be interesting for this case.
>>
>> The patch attached mainly uses some "undocumented" info to set DNS
>> default domain.
>> There is no official field for such info in ISAKMP, and also Cisco
>> uses its own "proprietary" field.
>> I'm using two Contivity servers, and each uses a different attribute
>> value for DNS domain.
>> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
>> Please test, with --debug 3, if other fields are also used for such purpose.
>>
>> The patch also identify and print 2 fields:
>> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
>> This is an alternate server IP, that can be used as backup
>> connection in case the server you are logged-in becomes unavailable.
>> Almost useless info. Nortel client does not seems using it too.
>> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
>> This could be interesting!
>> When I login with official client, I get a pop-up with a legal
>> disclaimer from my company
>> e.g. "don't use this connection if you are not authorized", or similar.
>> This text is exchanged through a standard qotd server placed beyond
>> Nortel concentrator.
>> The client receives the IP of qotd server inside this field, then
>> connects to it and get the string.
>>
>> It could be that the concentator closes the connection if the client
>> does not read the qotd string.
>> I have nothing to prove this crazy behaviour. My connections never got
>> such problem.
>> To test it, you need to connect vpnc, get qotd server IP and connect
>> to its port 17
>> e.g. "telnet x.y.w.z 17"
>> The attached patch, if run with "--debug 1", prints the string
>>> QOTD server: run:
>>> telnet x.y.w.z 17
>> so you can immediately copy the telnet string and paste it in another terminal.
>> Good luck!
>>
>> Best Regards,
>> Antonio Borneo
>>
>>
>> 2008/11/4 Dichi <dichoso [at] gmail>:
>>> Hi,
>>>
>>> I have same issue of ten second lasting connections, it works ok until
>>> something happens and connection got closed. This has been happening for a
>>> while and I can tell there are lot of people with same issue, my thinking is
>>> at some point concentrator validates client version and if it doesn't match
>>> allowed clients it closes connection with client.
>>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

borneo.antonio at gmail

Nov 22, 2008, 8:43 PM

Post #7 of 15 (3032 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Ciao Mariano,
sorry for not replying before, but I'm quite busy on my job.
Anyway, in spare time I'm making few tests on the issue of "client version".

Please try the patch in attachment and let me know.
Should be the right value for the client version required by your Nortel server.
In case it does not work yet, please change number 17 in the patch, in
place of 16.

Best Regards,
Antonio Borneo

On Mon, Nov 10, 2008 at 8:44 AM, Dichi <dichoso [at] gmail> wrote:
> That would be perfect Antonio, let me know if you need to test or anything else.
>
> Thanks,
> Mariano
>
> On Sun, Nov 9, 2008 at 1:17 AM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>> Ciao Mariano,
>> it's really positive that you can connect with the qotd server; it
>> means the vpn tunnel is up and running.
>> Also, having your server replying with a useful message, push me to
>> better implement this qotd connection. I was already thinking this
>> should be implemented to skip any legal issue related with banner
>> disclaimer, but I considered it a low priority task; now I changed
>> mind.
>>
>> I have to recover some old experiment I have done in the past.
>> I remember a situation in which the server ask for another
>> undocumented field, and client reply with a text string including OS
>> name and client version.
>> I skipped on purpose that situation, not mandatory for me, to avoid
>> sending such info.
>> At that time, I do not want to lie, by sending "fake" version and
>> claiming my vpnc is Nortel-something.
>> At the same time, I prefer not sending "vpnc version 0.5.1-352M". I
>> believe that a paranoid sysadmin could consider it as a cracker using
>> an "unofficial" and "unapproved" client, getting my account
>> immediately shut-down.
>>
>> To solve your situation, I have to go back to my old work, and we have
>> to send an "accepted" string.
>>
>> Best Regards,
>> Antonio Borneo
>>
>> On Sun, Nov 9, 2008 at 3:46 AM, Dichi <dichoso [at] gmail> wrote:
>>> Thanks, that helped
>>>
>>> I think this reinforce my theory of "client string", look what QOTD
>>> server gave me:
>>>
>>> Connectivity to this environment
>>> requires that you use a minimum version
>>> V04_91 of the Nortel VPN client. Please
>>> contact the Help Desk for assistance in
>>> obtaining the latest version of the Nortel
>>> VPN client.
>>>
>>> Is there any way to decode what apani/nortel clients send as "client
>>> version"???
>>>
>>> Thanks,
>>> Mariano
>>>
>>> On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>> Hi,
>>>> digging in the obscure data that Nortel client exchanges with server,
>>>> I have found some data that I hope could be interesting for this case.
>>>>
>>>> The patch attached mainly uses some "undocumented" info to set DNS
>>>> default domain.
>>>> There is no official field for such info in ISAKMP, and also Cisco
>>>> uses its own "proprietary" field.
>>>> I'm using two Contivity servers, and each uses a different attribute
>>>> value for DNS domain.
>>>> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
>>>> Please test, with --debug 3, if other fields are also used for such purpose.
>>>>
>>>> The patch also identify and print 2 fields:
>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
>>>> This is an alternate server IP, that can be used as backup
>>>> connection in case the server you are logged-in becomes unavailable.
>>>> Almost useless info. Nortel client does not seems using it too.
>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
>>>> This could be interesting!
>>>> When I login with official client, I get a pop-up with a legal
>>>> disclaimer from my company
>>>> e.g. "don't use this connection if you are not authorized", or similar.
>>>> This text is exchanged through a standard qotd server placed beyond
>>>> Nortel concentrator.
>>>> The client receives the IP of qotd server inside this field, then
>>>> connects to it and get the string.
>>>>
>>>> It could be that the concentator closes the connection if the client
>>>> does not read the qotd string.
>>>> I have nothing to prove this crazy behaviour. My connections never got
>>>> such problem.
>>>> To test it, you need to connect vpnc, get qotd server IP and connect
>>>> to its port 17
>>>> e.g. "telnet x.y.w.z 17"
>>>> The attached patch, if run with "--debug 1", prints the string
>>>>> QOTD server: run:
>>>>> telnet x.y.w.z 17
>>>> so you can immediately copy the telnet string and paste it in another terminal.
>>>> Good luck!
>>>>
>>>> Best Regards,
>>>> Antonio Borneo
>>>>
>>>>
>>>> 2008/11/4 Dichi <dichoso [at] gmail>:
>>>>> Hi,
>>>>>
>>>>> I have same issue of ten second lasting connections, it works ok until
>>>>> something happens and connection got closed. This has been happening for a
>>>>> while and I can tell there are lot of people with same issue, my thinking is
>>>>> at some point concentrator validates client version and if it doesn't match
>>>>> allowed clients it closes connection with client.
>>>>
>>>
>>
>

Attachments:

patch_V04_91.txt (0.44 KB)

dichoso at gmail

Nov 24, 2008, 6:12 AM

Post #8 of 15 (3026 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

I'm speechless, dude you're a genius!!!, I've my vpn connection up and
running for 15 about minutes now... :D . Now I'll provide further test
on:

1) Is it mandatory connect to QOTD server?
2) Stability

So you can include that patch into the trunk. You have no idea how
this improves my work efficiency!!!
Let's say bye bye to @p [at] n!!!

Thanks,
Mariano

On Sun, Nov 23, 2008 at 2:43 AM, Antonio Borneo
<borneo.antonio [at] gmail> wrote:
> Ciao Mariano,
> sorry for not replying before, but I'm quite busy on my job.
> Anyway, in spare time I'm making few tests on the issue of "client version".
>
> Please try the patch in attachment and let me know.
> Should be the right value for the client version required by your Nortel server.
> In case it does not work yet, please change number 17 in the patch, in
> place of 16.
>
> Best Regards,
> Antonio Borneo
>
> On Mon, Nov 10, 2008 at 8:44 AM, Dichi <dichoso [at] gmail> wrote:
>> That would be perfect Antonio, let me know if you need to test or anything else.
>>
>> Thanks,
>> Mariano
>>
>> On Sun, Nov 9, 2008 at 1:17 AM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>> Ciao Mariano,
>>> it's really positive that you can connect with the qotd server; it
>>> means the vpn tunnel is up and running.
>>> Also, having your server replying with a useful message, push me to
>>> better implement this qotd connection. I was already thinking this
>>> should be implemented to skip any legal issue related with banner
>>> disclaimer, but I considered it a low priority task; now I changed
>>> mind.
>>>
>>> I have to recover some old experiment I have done in the past.
>>> I remember a situation in which the server ask for another
>>> undocumented field, and client reply with a text string including OS
>>> name and client version.
>>> I skipped on purpose that situation, not mandatory for me, to avoid
>>> sending such info.
>>> At that time, I do not want to lie, by sending "fake" version and
>>> claiming my vpnc is Nortel-something.
>>> At the same time, I prefer not sending "vpnc version 0.5.1-352M". I
>>> believe that a paranoid sysadmin could consider it as a cracker using
>>> an "unofficial" and "unapproved" client, getting my account
>>> immediately shut-down.
>>>
>>> To solve your situation, I have to go back to my old work, and we have
>>> to send an "accepted" string.
>>>
>>> Best Regards,
>>> Antonio Borneo
>>>
>>> On Sun, Nov 9, 2008 at 3:46 AM, Dichi <dichoso [at] gmail> wrote:
>>>> Thanks, that helped
>>>>
>>>> I think this reinforce my theory of "client string", look what QOTD
>>>> server gave me:
>>>>
>>>> Connectivity to this environment
>>>> requires that you use a minimum version
>>>> V04_91 of the Nortel VPN client. Please
>>>> contact the Help Desk for assistance in
>>>> obtaining the latest version of the Nortel
>>>> VPN client.
>>>>
>>>> Is there any way to decode what apani/nortel clients send as "client
>>>> version"???
>>>>
>>>> Thanks,
>>>> Mariano
>>>>
>>>> On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>>> Hi,
>>>>> digging in the obscure data that Nortel client exchanges with server,
>>>>> I have found some data that I hope could be interesting for this case.
>>>>>
>>>>> The patch attached mainly uses some "undocumented" info to set DNS
>>>>> default domain.
>>>>> There is no official field for such info in ISAKMP, and also Cisco
>>>>> uses its own "proprietary" field.
>>>>> I'm using two Contivity servers, and each uses a different attribute
>>>>> value for DNS domain.
>>>>> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
>>>>> Please test, with --debug 3, if other fields are also used for such purpose.
>>>>>
>>>>> The patch also identify and print 2 fields:
>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
>>>>> This is an alternate server IP, that can be used as backup
>>>>> connection in case the server you are logged-in becomes unavailable.
>>>>> Almost useless info. Nortel client does not seems using it too.
>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
>>>>> This could be interesting!
>>>>> When I login with official client, I get a pop-up with a legal
>>>>> disclaimer from my company
>>>>> e.g. "don't use this connection if you are not authorized", or similar.
>>>>> This text is exchanged through a standard qotd server placed beyond
>>>>> Nortel concentrator.
>>>>> The client receives the IP of qotd server inside this field, then
>>>>> connects to it and get the string.
>>>>>
>>>>> It could be that the concentator closes the connection if the client
>>>>> does not read the qotd string.
>>>>> I have nothing to prove this crazy behaviour. My connections never got
>>>>> such problem.
>>>>> To test it, you need to connect vpnc, get qotd server IP and connect
>>>>> to its port 17
>>>>> e.g. "telnet x.y.w.z 17"
>>>>> The attached patch, if run with "--debug 1", prints the string
>>>>>> QOTD server: run:
>>>>>> telnet x.y.w.z 17
>>>>> so you can immediately copy the telnet string and paste it in another terminal.
>>>>> Good luck!
>>>>>
>>>>> Best Regards,
>>>>> Antonio Borneo
>>>>>
>>>>>
>>>>> 2008/11/4 Dichi <dichoso [at] gmail>:
>>>>>> Hi,
>>>>>>
>>>>>> I have same issue of ten second lasting connections, it works ok until
>>>>>> something happens and connection got closed. This has been happening for a
>>>>>> while and I can tell there are lot of people with same issue, my thinking is
>>>>>> at some point concentrator validates client version and if it doesn't match
>>>>>> allowed clients it closes connection with client.
>>>>>
>>>>
>>>
>>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

borneo.antonio at gmail

Nov 24, 2008, 7:10 AM

Post #9 of 15 (3023 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Very good! ;-)

I do not think it's mandatory connecting to QOTD server. The original
vpnc does not connect to it at all, and it works well. I do not see
reasons it should be different to you.

Could you please report if you used value 16 or 17?
I'm preparing a better patch to accomodate (almost) all the versions
of Nortel client, and this info helps.

Enjoy your new vpnc!
Antonio Borneo

On Mon, Nov 24, 2008 at 10:12 PM, Dichi <dichoso [at] gmail> wrote:
> I'm speechless, dude you're a genius!!!, I've my vpn connection up and
> running for 15 about minutes now... :D . Now I'll provide further test
> on:
>
> 1) Is it mandatory connect to QOTD server?
> 2) Stability
>
> So you can include that patch into the trunk. You have no idea how
> this improves my work efficiency!!!
> Let's say bye bye to @p [at] n!!!
>
> Thanks,
> Mariano
>
> On Sun, Nov 23, 2008 at 2:43 AM, Antonio Borneo
> <borneo.antonio [at] gmail> wrote:
>> Ciao Mariano,
>> sorry for not replying before, but I'm quite busy on my job.
>> Anyway, in spare time I'm making few tests on the issue of "client version".
>>
>> Please try the patch in attachment and let me know.
>> Should be the right value for the client version required by your Nortel server.
>> In case it does not work yet, please change number 17 in the patch, in
>> place of 16.
>>
>> Best Regards,
>> Antonio Borneo
>>
>> On Mon, Nov 10, 2008 at 8:44 AM, Dichi <dichoso [at] gmail> wrote:
>>> That would be perfect Antonio, let me know if you need to test or anything else.
>>>
>>> Thanks,
>>> Mariano
>>>
>>> On Sun, Nov 9, 2008 at 1:17 AM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>> Ciao Mariano,
>>>> it's really positive that you can connect with the qotd server; it
>>>> means the vpn tunnel is up and running.
>>>> Also, having your server replying with a useful message, push me to
>>>> better implement this qotd connection. I was already thinking this
>>>> should be implemented to skip any legal issue related with banner
>>>> disclaimer, but I considered it a low priority task; now I changed
>>>> mind.
>>>>
>>>> I have to recover some old experiment I have done in the past.
>>>> I remember a situation in which the server ask for another
>>>> undocumented field, and client reply with a text string including OS
>>>> name and client version.
>>>> I skipped on purpose that situation, not mandatory for me, to avoid
>>>> sending such info.
>>>> At that time, I do not want to lie, by sending "fake" version and
>>>> claiming my vpnc is Nortel-something.
>>>> At the same time, I prefer not sending "vpnc version 0.5.1-352M". I
>>>> believe that a paranoid sysadmin could consider it as a cracker using
>>>> an "unofficial" and "unapproved" client, getting my account
>>>> immediately shut-down.
>>>>
>>>> To solve your situation, I have to go back to my old work, and we have
>>>> to send an "accepted" string.
>>>>
>>>> Best Regards,
>>>> Antonio Borneo
>>>>
>>>> On Sun, Nov 9, 2008 at 3:46 AM, Dichi <dichoso [at] gmail> wrote:
>>>>> Thanks, that helped
>>>>>
>>>>> I think this reinforce my theory of "client string", look what QOTD
>>>>> server gave me:
>>>>>
>>>>> Connectivity to this environment
>>>>> requires that you use a minimum version
>>>>> V04_91 of the Nortel VPN client. Please
>>>>> contact the Help Desk for assistance in
>>>>> obtaining the latest version of the Nortel
>>>>> VPN client.
>>>>>
>>>>> Is there any way to decode what apani/nortel clients send as "client
>>>>> version"???
>>>>>
>>>>> Thanks,
>>>>> Mariano
>>>>>
>>>>> On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>>>> Hi,
>>>>>> digging in the obscure data that Nortel client exchanges with server,
>>>>>> I have found some data that I hope could be interesting for this case.
>>>>>>
>>>>>> The patch attached mainly uses some "undocumented" info to set DNS
>>>>>> default domain.
>>>>>> There is no official field for such info in ISAKMP, and also Cisco
>>>>>> uses its own "proprietary" field.
>>>>>> I'm using two Contivity servers, and each uses a different attribute
>>>>>> value for DNS domain.
>>>>>> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
>>>>>> Please test, with --debug 3, if other fields are also used for such purpose.
>>>>>>
>>>>>> The patch also identify and print 2 fields:
>>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
>>>>>> This is an alternate server IP, that can be used as backup
>>>>>> connection in case the server you are logged-in becomes unavailable.
>>>>>> Almost useless info. Nortel client does not seems using it too.
>>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
>>>>>> This could be interesting!
>>>>>> When I login with official client, I get a pop-up with a legal
>>>>>> disclaimer from my company
>>>>>> e.g. "don't use this connection if you are not authorized", or similar.
>>>>>> This text is exchanged through a standard qotd server placed beyond
>>>>>> Nortel concentrator.
>>>>>> The client receives the IP of qotd server inside this field, then
>>>>>> connects to it and get the string.
>>>>>>
>>>>>> It could be that the concentator closes the connection if the client
>>>>>> does not read the qotd string.
>>>>>> I have nothing to prove this crazy behaviour. My connections never got
>>>>>> such problem.
>>>>>> To test it, you need to connect vpnc, get qotd server IP and connect
>>>>>> to its port 17
>>>>>> e.g. "telnet x.y.w.z 17"
>>>>>> The attached patch, if run with "--debug 1", prints the string
>>>>>>> QOTD server: run:
>>>>>>> telnet x.y.w.z 17
>>>>>> so you can immediately copy the telnet string and paste it in another terminal.
>>>>>> Good luck!
>>>>>>
>>>>>> Best Regards,
>>>>>> Antonio Borneo
>>>>>>
>>>>>>
>>>>>> 2008/11/4 Dichi <dichoso [at] gmail>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have same issue of ten second lasting connections, it works ok until
>>>>>>> something happens and connection got closed. This has been happening for a
>>>>>>> while and I can tell there are lot of people with same issue, my thinking is
>>>>>>> at some point concentrator validates client version and if it doesn't match
>>>>>>> allowed clients it closes connection with client.
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

dichoso at gmail

Nov 24, 2008, 7:23 AM

Post #10 of 15 (3025 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

16 is what I've used.

On Mon, Nov 24, 2008 at 1:10 PM, Antonio Borneo
<borneo.antonio [at] gmail> wrote:
> Very good! ;-)
>
> I do not think it's mandatory connecting to QOTD server. The original
> vpnc does not connect to it at all, and it works well. I do not see
> reasons it should be different to you.
>
> Could you please report if you used value 16 or 17?
> I'm preparing a better patch to accomodate (almost) all the versions
> of Nortel client, and this info helps.
>
> Enjoy your new vpnc!
> Antonio Borneo
>
> On Mon, Nov 24, 2008 at 10:12 PM, Dichi <dichoso [at] gmail> wrote:
>> I'm speechless, dude you're a genius!!!, I've my vpn connection up and
>> running for 15 about minutes now... :D . Now I'll provide further test
>> on:
>>
>> 1) Is it mandatory connect to QOTD server?
>> 2) Stability
>>
>> So you can include that patch into the trunk. You have no idea how
>> this improves my work efficiency!!!
>> Let's say bye bye to @p [at] n!!!
>>
>> Thanks,
>> Mariano
>>
>> On Sun, Nov 23, 2008 at 2:43 AM, Antonio Borneo
>> <borneo.antonio [at] gmail> wrote:
>>> Ciao Mariano,
>>> sorry for not replying before, but I'm quite busy on my job.
>>> Anyway, in spare time I'm making few tests on the issue of "client version".
>>>
>>> Please try the patch in attachment and let me know.
>>> Should be the right value for the client version required by your Nortel server.
>>> In case it does not work yet, please change number 17 in the patch, in
>>> place of 16.
>>>
>>> Best Regards,
>>> Antonio Borneo
>>>
>>> On Mon, Nov 10, 2008 at 8:44 AM, Dichi <dichoso [at] gmail> wrote:
>>>> That would be perfect Antonio, let me know if you need to test or anything else.
>>>>
>>>> Thanks,
>>>> Mariano
>>>>
>>>> On Sun, Nov 9, 2008 at 1:17 AM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>>> Ciao Mariano,
>>>>> it's really positive that you can connect with the qotd server; it
>>>>> means the vpn tunnel is up and running.
>>>>> Also, having your server replying with a useful message, push me to
>>>>> better implement this qotd connection. I was already thinking this
>>>>> should be implemented to skip any legal issue related with banner
>>>>> disclaimer, but I considered it a low priority task; now I changed
>>>>> mind.
>>>>>
>>>>> I have to recover some old experiment I have done in the past.
>>>>> I remember a situation in which the server ask for another
>>>>> undocumented field, and client reply with a text string including OS
>>>>> name and client version.
>>>>> I skipped on purpose that situation, not mandatory for me, to avoid
>>>>> sending such info.
>>>>> At that time, I do not want to lie, by sending "fake" version and
>>>>> claiming my vpnc is Nortel-something.
>>>>> At the same time, I prefer not sending "vpnc version 0.5.1-352M". I
>>>>> believe that a paranoid sysadmin could consider it as a cracker using
>>>>> an "unofficial" and "unapproved" client, getting my account
>>>>> immediately shut-down.
>>>>>
>>>>> To solve your situation, I have to go back to my old work, and we have
>>>>> to send an "accepted" string.
>>>>>
>>>>> Best Regards,
>>>>> Antonio Borneo
>>>>>
>>>>> On Sun, Nov 9, 2008 at 3:46 AM, Dichi <dichoso [at] gmail> wrote:
>>>>>> Thanks, that helped
>>>>>>
>>>>>> I think this reinforce my theory of "client string", look what QOTD
>>>>>> server gave me:
>>>>>>
>>>>>> Connectivity to this environment
>>>>>> requires that you use a minimum version
>>>>>> V04_91 of the Nortel VPN client. Please
>>>>>> contact the Help Desk for assistance in
>>>>>> obtaining the latest version of the Nortel
>>>>>> VPN client.
>>>>>>
>>>>>> Is there any way to decode what apani/nortel clients send as "client
>>>>>> version"???
>>>>>>
>>>>>> Thanks,
>>>>>> Mariano
>>>>>>
>>>>>> On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>>>>> Hi,
>>>>>>> digging in the obscure data that Nortel client exchanges with server,
>>>>>>> I have found some data that I hope could be interesting for this case.
>>>>>>>
>>>>>>> The patch attached mainly uses some "undocumented" info to set DNS
>>>>>>> default domain.
>>>>>>> There is no official field for such info in ISAKMP, and also Cisco
>>>>>>> uses its own "proprietary" field.
>>>>>>> I'm using two Contivity servers, and each uses a different attribute
>>>>>>> value for DNS domain.
>>>>>>> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
>>>>>>> Please test, with --debug 3, if other fields are also used for such purpose.
>>>>>>>
>>>>>>> The patch also identify and print 2 fields:
>>>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
>>>>>>> This is an alternate server IP, that can be used as backup
>>>>>>> connection in case the server you are logged-in becomes unavailable.
>>>>>>> Almost useless info. Nortel client does not seems using it too.
>>>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
>>>>>>> This could be interesting!
>>>>>>> When I login with official client, I get a pop-up with a legal
>>>>>>> disclaimer from my company
>>>>>>> e.g. "don't use this connection if you are not authorized", or similar.
>>>>>>> This text is exchanged through a standard qotd server placed beyond
>>>>>>> Nortel concentrator.
>>>>>>> The client receives the IP of qotd server inside this field, then
>>>>>>> connects to it and get the string.
>>>>>>>
>>>>>>> It could be that the concentator closes the connection if the client
>>>>>>> does not read the qotd string.
>>>>>>> I have nothing to prove this crazy behaviour. My connections never got
>>>>>>> such problem.
>>>>>>> To test it, you need to connect vpnc, get qotd server IP and connect
>>>>>>> to its port 17
>>>>>>> e.g. "telnet x.y.w.z 17"
>>>>>>> The attached patch, if run with "--debug 1", prints the string
>>>>>>>> QOTD server: run:
>>>>>>>> telnet x.y.w.z 17
>>>>>>> so you can immediately copy the telnet string and paste it in another terminal.
>>>>>>> Good luck!
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Antonio Borneo
>>>>>>>
>>>>>>>
>>>>>>> 2008/11/4 Dichi <dichoso [at] gmail>:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have same issue of ten second lasting connections, it works ok until
>>>>>>>> something happens and connection got closed. This has been happening for a
>>>>>>>> while and I can tell there are lot of people with same issue, my thinking is
>>>>>>>> at some point concentrator validates client version and if it doesn't match
>>>>>>>> allowed clients it closes connection with client.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

borneo.antonio at gmail

Nov 26, 2008, 5:34 AM

Post #11 of 15 (3002 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Joerg,
the patch I sent for this case, that helped Mariano's connection,
should NOT be added to code in svn.
It does not provide backward compatibility, so the risk is having vpnc
not working anymore for some user.

I'm working at a wider patch that, while supporting also Mariano's
case, provides current vpnc behavior as default.

Other news: Today I have received a second hand Nortel Concentrator
with which I want to run deeper tests for vpnc. It is an old model,
already out of production, but still working. Configuration is quite
hard; I hope having enough spare time next week-end.

Best Regards,
Antonio

On Mon, Nov 24, 2008 at 10:12 PM, Dichi <dichoso [at] gmail> wrote:
> I'm speechless, dude you're a genius!!!, I've my vpn connection up and
> running for 15 about minutes now... :D . Now I'll provide further test
> on:
>
> 1) Is it mandatory connect to QOTD server?
> 2) Stability
>
> So you can include that patch into the trunk. You have no idea how
> this improves my work efficiency!!!
> Let's say bye bye to @p [at] n!!!
>
> Thanks,
> Mariano
>
> On Sun, Nov 23, 2008 at 2:43 AM, Antonio Borneo
> <borneo.antonio [at] gmail> wrote:
>> Ciao Mariano,
>> sorry for not replying before, but I'm quite busy on my job.
>> Anyway, in spare time I'm making few tests on the issue of "client version".
>>
>> Please try the patch in attachment and let me know.
>> Should be the right value for the client version required by your Nortel server.
>> In case it does not work yet, please change number 17 in the patch, in
>> place of 16.
>>
>> Best Regards,
>> Antonio Borneo
>>
>> On Mon, Nov 10, 2008 at 8:44 AM, Dichi <dichoso [at] gmail> wrote:
>>> That would be perfect Antonio, let me know if you need to test or anything else.
>>>
>>> Thanks,
>>> Mariano
>>>
>>> On Sun, Nov 9, 2008 at 1:17 AM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>> Ciao Mariano,
>>>> it's really positive that you can connect with the qotd server; it
>>>> means the vpn tunnel is up and running.
>>>> Also, having your server replying with a useful message, push me to
>>>> better implement this qotd connection. I was already thinking this
>>>> should be implemented to skip any legal issue related with banner
>>>> disclaimer, but I considered it a low priority task; now I changed
>>>> mind.
>>>>
>>>> I have to recover some old experiment I have done in the past.
>>>> I remember a situation in which the server ask for another
>>>> undocumented field, and client reply with a text string including OS
>>>> name and client version.
>>>> I skipped on purpose that situation, not mandatory for me, to avoid
>>>> sending such info.
>>>> At that time, I do not want to lie, by sending "fake" version and
>>>> claiming my vpnc is Nortel-something.
>>>> At the same time, I prefer not sending "vpnc version 0.5.1-352M". I
>>>> believe that a paranoid sysadmin could consider it as a cracker using
>>>> an "unofficial" and "unapproved" client, getting my account
>>>> immediately shut-down.
>>>>
>>>> To solve your situation, I have to go back to my old work, and we have
>>>> to send an "accepted" string.
>>>>
>>>> Best Regards,
>>>> Antonio Borneo
>>>>
>>>> On Sun, Nov 9, 2008 at 3:46 AM, Dichi <dichoso [at] gmail> wrote:
>>>>> Thanks, that helped
>>>>>
>>>>> I think this reinforce my theory of "client string", look what QOTD
>>>>> server gave me:
>>>>>
>>>>> Connectivity to this environment
>>>>> requires that you use a minimum version
>>>>> V04_91 of the Nortel VPN client. Please
>>>>> contact the Help Desk for assistance in
>>>>> obtaining the latest version of the Nortel
>>>>> VPN client.
>>>>>
>>>>> Is there any way to decode what apani/nortel clients send as "client
>>>>> version"???
>>>>>
>>>>> Thanks,
>>>>> Mariano
>>>>>
>>>>> On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <borneo.antonio [at] gmail> wrote:
>>>>>> Hi,
>>>>>> digging in the obscure data that Nortel client exchanges with server,
>>>>>> I have found some data that I hope could be interesting for this case.
>>>>>>
>>>>>> The patch attached mainly uses some "undocumented" info to set DNS
>>>>>> default domain.
>>>>>> There is no official field for such info in ISAKMP, and also Cisco
>>>>>> uses its own "proprietary" field.
>>>>>> I'm using two Contivity servers, and each uses a different attribute
>>>>>> value for DNS domain.
>>>>>> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
>>>>>> Please test, with --debug 3, if other fields are also used for such purpose.
>>>>>>
>>>>>> The patch also identify and print 2 fields:
>>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
>>>>>> This is an alternate server IP, that can be used as backup
>>>>>> connection in case the server you are logged-in becomes unavailable.
>>>>>> Almost useless info. Nortel client does not seems using it too.
>>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
>>>>>> This could be interesting!
>>>>>> When I login with official client, I get a pop-up with a legal
>>>>>> disclaimer from my company
>>>>>> e.g. "don't use this connection if you are not authorized", or similar.
>>>>>> This text is exchanged through a standard qotd server placed beyond
>>>>>> Nortel concentrator.
>>>>>> The client receives the IP of qotd server inside this field, then
>>>>>> connects to it and get the string.
>>>>>>
>>>>>> It could be that the concentator closes the connection if the client
>>>>>> does not read the qotd string.
>>>>>> I have nothing to prove this crazy behaviour. My connections never got
>>>>>> such problem.
>>>>>> To test it, you need to connect vpnc, get qotd server IP and connect
>>>>>> to its port 17
>>>>>> e.g. "telnet x.y.w.z 17"
>>>>>> The attached patch, if run with "--debug 1", prints the string
>>>>>>> QOTD server: run:
>>>>>>> telnet x.y.w.z 17
>>>>>> so you can immediately copy the telnet string and paste it in another terminal.
>>>>>> Good luck!
>>>>>>
>>>>>> Best Regards,
>>>>>> Antonio Borneo
>>>>>>
>>>>>>
>>>>>> 2008/11/4 Dichi <dichoso [at] gmail>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have same issue of ten second lasting connections, it works ok until
>>>>>>> something happens and connection got closed. This has been happening for a
>>>>>>> while and I can tell there are lot of people with same issue, my thinking is
>>>>>>> at some point concentrator validates client version and if it doesn't match
>>>>>>> allowed clients it closes connection with client.
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

gofman.mike at gmail

Nov 26, 2008, 6:17 AM

Post #12 of 15 (3006 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

If you need need any help testing things just drop me a line.

On Wed, Nov 26, 2008 at 8:34 AM, Antonio Borneo <borneo.antonio [at] gmail>wrote:

> Joerg,
> the patch I sent for this case, that helped Mariano's connection,
> should NOT be added to code in svn.
> It does not provide backward compatibility, so the risk is having vpnc
> not working anymore for some user.
>
> I'm working at a wider patch that, while supporting also Mariano's
> case, provides current vpnc behavior as default.
>
> Other news: Today I have received a second hand Nortel Concentrator
> with which I want to run deeper tests for vpnc. It is an old model,
> already out of production, but still working. Configuration is quite
> hard; I hope having enough spare time next week-end.
>
> Best Regards,
> Antonio
>
> On Mon, Nov 24, 2008 at 10:12 PM, Dichi <dichoso [at] gmail> wrote:
> > I'm speechless, dude you're a genius!!!, I've my vpn connection up and
> > running for 15 about minutes now... :D . Now I'll provide further test
> > on:
> >
> > 1) Is it mandatory connect to QOTD server?
> > 2) Stability
> >
> > So you can include that patch into the trunk. You have no idea how
> > this improves my work efficiency!!!
> > Let's say bye bye to @p [at] n!!!
> >
> > Thanks,
> > Mariano
> >
> > On Sun, Nov 23, 2008 at 2:43 AM, Antonio Borneo
> > <borneo.antonio [at] gmail> wrote:
> >> Ciao Mariano,
> >> sorry for not replying before, but I'm quite busy on my job.
> >> Anyway, in spare time I'm making few tests on the issue of "client
> version".
> >>
> >> Please try the patch in attachment and let me know.
> >> Should be the right value for the client version required by your Nortel
> server.
> >> In case it does not work yet, please change number 17 in the patch, in
> >> place of 16.
> >>
> >> Best Regards,
> >> Antonio Borneo
> >>
> >> On Mon, Nov 10, 2008 at 8:44 AM, Dichi <dichoso [at] gmail> wrote:
> >>> That would be perfect Antonio, let me know if you need to test or
> anything else.
> >>>
> >>> Thanks,
> >>> Mariano
> >>>
> >>> On Sun, Nov 9, 2008 at 1:17 AM, Antonio Borneo <
> borneo.antonio [at] gmail> wrote:
> >>>> Ciao Mariano,
> >>>> it's really positive that you can connect with the qotd server; it
> >>>> means the vpn tunnel is up and running.
> >>>> Also, having your server replying with a useful message, push me to
> >>>> better implement this qotd connection. I was already thinking this
> >>>> should be implemented to skip any legal issue related with banner
> >>>> disclaimer, but I considered it a low priority task; now I changed
> >>>> mind.
> >>>>
> >>>> I have to recover some old experiment I have done in the past.
> >>>> I remember a situation in which the server ask for another
> >>>> undocumented field, and client reply with a text string including OS
> >>>> name and client version.
> >>>> I skipped on purpose that situation, not mandatory for me, to avoid
> >>>> sending such info.
> >>>> At that time, I do not want to lie, by sending "fake" version and
> >>>> claiming my vpnc is Nortel-something.
> >>>> At the same time, I prefer not sending "vpnc version 0.5.1-352M". I
> >>>> believe that a paranoid sysadmin could consider it as a cracker using
> >>>> an "unofficial" and "unapproved" client, getting my account
> >>>> immediately shut-down.
> >>>>
> >>>> To solve your situation, I have to go back to my old work, and we have
> >>>> to send an "accepted" string.
> >>>>
> >>>> Best Regards,
> >>>> Antonio Borneo
> >>>>
> >>>> On Sun, Nov 9, 2008 at 3:46 AM, Dichi <dichoso [at] gmail> wrote:
> >>>>> Thanks, that helped
> >>>>>
> >>>>> I think this reinforce my theory of "client string", look what QOTD
> >>>>> server gave me:
> >>>>>
> >>>>> Connectivity to this environment
> >>>>> requires that you use a minimum version
> >>>>> V04_91 of the Nortel VPN client. Please
> >>>>> contact the Help Desk for assistance in
> >>>>> obtaining the latest version of the Nortel
> >>>>> VPN client.
> >>>>>
> >>>>> Is there any way to decode what apani/nortel clients send as "client
> >>>>> version"???
> >>>>>
> >>>>> Thanks,
> >>>>> Mariano
> >>>>>
> >>>>> On Sat, Nov 8, 2008 at 3:24 PM, Antonio Borneo <
> borneo.antonio [at] gmail> wrote:
> >>>>>> Hi,
> >>>>>> digging in the obscure data that Nortel client exchanges with
> server,
> >>>>>> I have found some data that I hope could be interesting for this
> case.
> >>>>>>
> >>>>>> The patch attached mainly uses some "undocumented" info to set DNS
> >>>>>> default domain.
> >>>>>> There is no official field for such info in ISAKMP, and also Cisco
> >>>>>> uses its own "proprietary" field.
> >>>>>> I'm using two Contivity servers, and each uses a different attribute
> >>>>>> value for DNS domain.
> >>>>>> I have named them ISAKMP_MODECFG_ATTRIB_NORTEL_DEF_DOMAIN_A and _B.
> >>>>>> Please test, with --debug 3, if other fields are also used for such
> purpose.
> >>>>>>
> >>>>>> The patch also identify and print 2 fields:
> >>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_ALT_SERVER
> >>>>>> This is an alternate server IP, that can be used as backup
> >>>>>> connection in case the server you are logged-in becomes unavailable.
> >>>>>> Almost useless info. Nortel client does not seems using it too.
> >>>>>> - ISAKMP_MODECFG_ATTRIB_NORTEL_QOTD_SERVER
> >>>>>> This could be interesting!
> >>>>>> When I login with official client, I get a pop-up with a legal
> >>>>>> disclaimer from my company
> >>>>>> e.g. "don't use this connection if you are not authorized", or
> similar.
> >>>>>> This text is exchanged through a standard qotd server placed beyond
> >>>>>> Nortel concentrator.
> >>>>>> The client receives the IP of qotd server inside this field, then
> >>>>>> connects to it and get the string.
> >>>>>>
> >>>>>> It could be that the concentator closes the connection if the client
> >>>>>> does not read the qotd string.
> >>>>>> I have nothing to prove this crazy behaviour. My connections never
> got
> >>>>>> such problem.
> >>>>>> To test it, you need to connect vpnc, get qotd server IP and connect
> >>>>>> to its port 17
> >>>>>> e.g. "telnet x.y.w.z 17"
> >>>>>> The attached patch, if run with "--debug 1", prints the string
> >>>>>>> QOTD server: run:
> >>>>>>> telnet x.y.w.z 17
> >>>>>> so you can immediately copy the telnet string and paste it in
> another terminal.
> >>>>>> Good luck!
> >>>>>>
> >>>>>> Best Regards,
> >>>>>> Antonio Borneo
> >>>>>>
> >>>>>>
> >>>>>> 2008/11/4 Dichi <dichoso [at] gmail>:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I have same issue of ten second lasting connections, it works ok
> until
> >>>>>>> something happens and connection got closed. This has been
> happening for a
> >>>>>>> while and I can tell there are lot of people with same issue, my
> thinking is
> >>>>>>> at some point concentrator validates client version and if it
> doesn't match
> >>>>>>> allowed clients it closes connection with client.
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/<http://www.unix-ag.uni-kl.de/%7Emassar/vpnc/>
>

jmvpnc at loplof

Nov 26, 2008, 6:34 AM

Post #13 of 15 (3010 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

On Wed, Nov 26, 2008 at 09:34:58PM +0800, Antonio Borneo wrote:
> the patch I sent for this case, that helped Mariano's connection,
> should NOT be added to code in svn.

OK, that's easy to do :-)

>
> Other news: Today I have received a second hand Nortel Concentrator
> with which I want to run deeper tests for vpnc. It is an old model,
> already out of production, but still working. Configuration is quite
> hard; I hope having enough spare time next week-end.

That's very good news! Happy hacking....

Ciao
Joerg
--
Joerg Mayer <jmayer [at] loplof>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

borneo.antonio at gmail

Dec 9, 2008, 6:26 AM

Post #14 of 15 (2898 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

Hi,
in attachment the patch to "control" the version of the client for vpnc-nortel.

It took me some time to validate it on my new (second hand) Nortel Concentrator.
The main problem is that I'm currently UN-able to configure the
concentrator for "group" authentication so, in my tests, I had to mix
this new patch for client version with another patch (not merged yet)
for Nortel username authentication. In doing this I have also found an
issue in the latter patch, on which I still need to work on.

A configuration option in the Nortel Concentrator, push the need to
control client version in vpnc.
For security reasons (I suppose) it is possible to forbid any login
attempt by clients older than a selected version.
Mariano, the originator of this thread, was unable to login since the
concentrator was asking for version V04_91 or above, while vpnc was
mimic only V04_15.

An "optional" banner can be configured in the qotd server in case of
login refused by incorrect client version (as Mariano reports too).

In theory, forcing a high value of version will let you pass every check.
But the risk is to encounter a new undocumented feature not supported
yet. In this case, vpnc could still fail.
This is why I propose, with this patch, the possibility to configure
the desired version.

The official Nortel Client embeds client version in the first packet
of ISAKMP Phase 1.
During the "Security Association", in each "Transform" proposal, the
undocumented field 0x7fff is added, and its value codes the client
version, as below.
> BEGIN_PARSE
> ...
> PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)
> ...
> PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)
> ...
> PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)
> ...
> t.attributes.type: 7fff (IKE_ATTRIB_NORTEL_CLIENT_ID) <==
> t.attributes.u.attr_16: 000a (NORTEL_CLIENT_V04_15) <==
> DONE PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)
> ...
> DONE PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)
> ...
> DONE PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)
> ...
> PARSE_OK

Now, you can select the value either through command line
"--nortel-client-id" or through config file field "Nortel Client ID".
It is possible to use directly the integer value (e.g.
"--nortel-client-id 10") or a more understandable string (e.g.
"--nortel-client-id V04_15"). To list all the couples string-integer
use the command line "--nortel-client-id list".

The value 65535 ("VEXTRA") is used to code "special" client versions
(or not Nortel), e.g. it is used by Apani Linux client.
In this case, an additional request is sent by the server in Phase 2,
before the XAuth authentication. The client's reply contains the
version as ascii string.
> receiving: <========================
> BEGIN_PARSE
> ...
> PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
> next_type: 00 (ISAKMP_PAYLOAD_NONE)
> length: 0010
> modecfg.type: 01 (ISAKMP_MODECFG_CFG_REQUEST)
> modecfg.id: 42dd
> t.attributes.type: 4011 (ISAKMP_MODECFG_ATTRIB_NORTEL_UNKNOWN_4011)
> t.attributes.u.attr_16: 0000
> t.attributes.type: 4012 (ISAKMP_MODECFG_ATTRIB_NORTEL_CLIENT_ID)
> t.attributes.u.lots.length: 0000
> t.attributes.u.lots.data:
> DONE PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
> ...
> PARSE_OK
> ...
> sending: ========================>
> BEGIN_PARSE
> ...
> PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
> next_type: 00 (ISAKMP_PAYLOAD_NONE)
> length: 0039
> modecfg.type: 02 (ISAKMP_MODECFG_CFG_REPLY)
> modecfg.id: 42dd
> t.attributes.type: 4012 (ISAKMP_MODECFG_ATTRIB_NORTEL_CLIENT_ID)
> t.attributes.u.lots.length: 0029
> t.attributes.u.lots.data:
> 43697363 6f205379 7374656d 73205650 4e20436c 69656e74 20302e35 2e322d33
> 37384d3a 4c696e75 78
> t.attributes.type: 4011 (ISAKMP_MODECFG_ATTRIB_NORTEL_UNKNOWN_4011)
> t.attributes.u.attr_16: 0000
> DONE PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
> ...
> PARSE_OK
The ascii string is controlled by the command line "--application-version"

The attached patch does not change the default behaviour of vpnc, so
can be applied to vpnc-nortel branch without any backward
compatibility issue.

Best Regards,
Antonio Borneo

Attachments:

patch_nortel_version.txt (7.72 KB)

dichoso at gmail

Dec 9, 2008, 8:02 AM

Post #15 of 15 (2898 views)
Permalink

Re: Disconnects after 10 seconds [In reply to]

We've been using patched vpnc since you sent me the patch. Since then
It was working perfect, no major issues, seems to be stable.

2008/12/9 Antonio Borneo <borneo.antonio [at] gmail>:
> Hi,
> in attachment the patch to "control" the version of the client for vpnc-nortel.
>
> It took me some time to validate it on my new (second hand) Nortel Concentrator.
> The main problem is that I'm currently UN-able to configure the
> concentrator for "group" authentication so, in my tests, I had to mix
> this new patch for client version with another patch (not merged yet)
> for Nortel username authentication. In doing this I have also found an
> issue in the latter patch, on which I still need to work on.
>
> A configuration option in the Nortel Concentrator, push the need to
> control client version in vpnc.
> For security reasons (I suppose) it is possible to forbid any login
> attempt by clients older than a selected version.
> Mariano, the originator of this thread, was unable to login since the
> concentrator was asking for version V04_91 or above, while vpnc was
> mimic only V04_15.
>
> An "optional" banner can be configured in the qotd server in case of
> login refused by incorrect client version (as Mariano reports too).
>
> In theory, forcing a high value of version will let you pass every check.
> But the risk is to encounter a new undocumented feature not supported
> yet. In this case, vpnc could still fail.
> This is why I propose, with this patch, the possibility to configure
> the desired version.
>
> The official Nortel Client embeds client version in the first packet
> of ISAKMP Phase 1.
> During the "Security Association", in each "Transform" proposal, the
> undocumented field 0x7fff is added, and its value codes the client
> version, as below.
>> BEGIN_PARSE
>> ...
>> PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)
>> ...
>> PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)
>> ...
>> PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)
>> ...
>> t.attributes.type: 7fff (IKE_ATTRIB_NORTEL_CLIENT_ID) <==
>> t.attributes.u.attr_16: 000a (NORTEL_CLIENT_V04_15) <==
>> DONE PARSING PAYLOAD type: 03 (ISAKMP_PAYLOAD_T)
>> ...
>> DONE PARSING PAYLOAD type: 02 (ISAKMP_PAYLOAD_P)
>> ...
>> DONE PARSING PAYLOAD type: 01 (ISAKMP_PAYLOAD_SA)
>> ...
>> PARSE_OK
>
> Now, you can select the value either through command line
> "--nortel-client-id" or through config file field "Nortel Client ID".
> It is possible to use directly the integer value (e.g.
> "--nortel-client-id 10") or a more understandable string (e.g.
> "--nortel-client-id V04_15"). To list all the couples string-integer
> use the command line "--nortel-client-id list".
>
> The value 65535 ("VEXTRA") is used to code "special" client versions
> (or not Nortel), e.g. it is used by Apani Linux client.
> In this case, an additional request is sent by the server in Phase 2,
> before the XAuth authentication. The client's reply contains the
> version as ascii string.
>> receiving: <========================
>> BEGIN_PARSE
>> ...
>> PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
>> next_type: 00 (ISAKMP_PAYLOAD_NONE)
>> length: 0010
>> modecfg.type: 01 (ISAKMP_MODECFG_CFG_REQUEST)
>> modecfg.id: 42dd
>> t.attributes.type: 4011 (ISAKMP_MODECFG_ATTRIB_NORTEL_UNKNOWN_4011)
>> t.attributes.u.attr_16: 0000
>> t.attributes.type: 4012 (ISAKMP_MODECFG_ATTRIB_NORTEL_CLIENT_ID)
>> t.attributes.u.lots.length: 0000
>> t.attributes.u.lots.data:
>> DONE PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
>> ...
>> PARSE_OK
>> ...
>> sending: ========================>
>> BEGIN_PARSE
>> ...
>> PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
>> next_type: 00 (ISAKMP_PAYLOAD_NONE)
>> length: 0039
>> modecfg.type: 02 (ISAKMP_MODECFG_CFG_REPLY)
>> modecfg.id: 42dd
>> t.attributes.type: 4012 (ISAKMP_MODECFG_ATTRIB_NORTEL_CLIENT_ID)
>> t.attributes.u.lots.length: 0029
>> t.attributes.u.lots.data:
>> 43697363 6f205379 7374656d 73205650 4e20436c 69656e74 20302e35 2e322d33
>> 37384d3a 4c696e75 78
>> t.attributes.type: 4011 (ISAKMP_MODECFG_ATTRIB_NORTEL_UNKNOWN_4011)
>> t.attributes.u.attr_16: 0000
>> DONE PARSING PAYLOAD type: 0e (ISAKMP_PAYLOAD_MODECFG_ATTR)
>> ...
>> PARSE_OK
> The ascii string is controlled by the command line "--application-version"
>
> The attached patch does not change the default behaviour of vpnc, so
> can be applied to vpnc-nortel branch without any backward
> compatibility issue.
>
> Best Regards,
> Antonio Borneo
>
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>
>
_______________________________________________
vpnc-devel mailing list
vpnc-devel [at] unix-ag
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads