Mailing List Archive

On Sun, Jul 1, 2012 at 4:49 AM, Glen Henderson <gahenders@gmail.com> wrote:
>
> I have seen this issue referenced before but I have not yet come across a resolution.  I am using vpnc version 517 on Mac connecting to a Nortel VPN using token based authentication in nortel-udp NAT mode.  I am able to connect and ping remote resources but after 30 seconds or so my session is disconnected.  I saw mention a while back that there may be an unsupported NAT mode at work here.  Is this a known issue or should I upload some debug logs to help diagnose this problem.
>
> Cheers
> Glen
> Gahenders@gmail.com

Hi Glen,
it seams I forgot to commit one patch about "Quote Of The Day" server
in Nortel branch.
I need to recover the old patch to rebase and commit it.
In the mean time, here are some info for you to check.

Using the official Nortel client and after the IPSec connection is
established, a pop-up window is opened containing a message prepared
by your network administrator.
A QOTD server is responsible to send the content of the pop-up window
to the client.
Current vpnc-nortel does not decode the QOTD server info, does not
contact the server, does not print the pop-up message.
The QOTD server is inside the vpn protected network, so can only be
accessed when IPSec connection is active.

Network administrator can instruct the concentrator to check the
version of the client.
If version is older than expected, the concentrator replaces the QOTD
message with an automatic error message reporting the lowest allowed
version of the client.
To print the error message, the concentrator have to complete the
set-up of IPSec network, let client connect to QOTD server (inside the
protected network), then drop the connection after 30 seconds timeout.

I think this is the reason of your issue.

Now, how to verify:
run vpnc-nortel with flag "--debug 3" and perform a complete
connection (that would be dropped in 30 seconds).
Search inside the output the dumped packet with header:
"S6.2 phase2_config receive modecfg"
Inside this packet look for following lines:
t.attributes.type: 400e (unknown)
t.attributes.u.lots.length: 0004
t.attributes.u.lots.data: 0a000115
This is the info you need to connect to the QOTD server.
The attribute type "400e" is QOTD server; following data reports IP
address of the server.
In my case it is 10.0.1.21, written in hex format.

Now you have all info you need.
Connect again to your server and be ready to use the 30 seconds of
working connection to type in a shell (of course, replace with the IP
address you get):
telnet 10.0.1.21 17
You will get the error message from the server.

Once you know what is the client version that is expected, just tune
the config file of your vpnc with proper field "Nortel Client ID" or
try with command line flag "--nortel-client-id".
You can print all the available codes with "vpnc --nortel-client-id list"

Let me know if this works

Best Regards
Antonio Borneo
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Hi Glen,

I'm putting the mailing list in copy, since other users of vpnc-nortel
could face same issue.

My experience is that the accept/decline button acts on client only.
No message is sent back to the server.
The QOTD server just provides fixed reply to any telnet session and
close the connection at the end of the message.

Try to set a higher value for "--nortel-client-id". Default is 10 or "V04_15".
The maximum value 65535 "VEXTRA" is used by the Linux client
cvc_linux, but I'm not sure can work with every Nortel concentrator.

Best Regards,
Antonio Borneo

On Sun, Jul 1, 2012 at 12:01 PM, Glen Henderson <gahenders@gmail.com> wrote:
> After thinking it over, I realize that clicking the accept button may
> not send anything on the network. The "accept/decline" button in the
> Windows client may simply terminate the connection at the client end.
> There may not be anything at the server end waiting for a formal
> 'accept' of the AUP. If that is the case, I am back to trying to
> figure out why my connection is terminating after a brief period of
> connectivity (around 30 secs). I am assuming that since I am getting
> the AUP message from the QOTD, everything is OK from the server's
> perspective.
>
> I have traced the successful windows packet exchanges and the only
> unusual things I see after the QOTD exchange are:
>
> 1. an IGMPv3 membership report
> 2. Some NBNS multi-home registration
>
> That is about it. From the system log it appears that the connection
> is terminated by the peer.
>
>
> On Sat, Jun 30, 2012 at 9:36 PM, Glen Henderson <gahenders@gmail.com> wrote:
>> You are definitely sending me on the right track. By querying that
>> QOTD server I received the typical "acceptable use policy" message
>> that I see presented to me when I connect using my Windows-based
>> Nortel client. After connecting using the Windows Nortel client a
>> dialog box with "Accept" or "Close" options is presented, implying
>> that I need to send a message somewhere to indicate that I accept the
>> AUP. When I telneted to the QOTD server, the AUP message was printed
>> out and then the telnet session closed.
>>
>> Do you have any insights on where I would send a "I accept" message in
>> such a scenario? I am assuming that since the Nortel VPN does not get
>> the "I accept" message it is dropping my connection.
>>
>> This is significant progress though. I appreciate the help.
>>
>> Cheers
>> Glen
>>
>> On Sat, Jun 30, 2012 at 7:40 PM, Antonio Borneo
>> <borneo.antonio@gmail.com> wrote:
>>> On Sun, Jul 1, 2012 at 4:49 AM, Glen Henderson <gahenders@gmail.com> wrote:
>>>>
>>>> I have seen this issue referenced before but I have not yet come across a resolution. I am using vpnc version 517 on Mac connecting to a Nortel VPN using token based authentication in nortel-udp NAT mode. I am able to connect and ping remote resources but after 30 seconds or so my session is disconnected. I saw mention a while back that there may be an unsupported NAT mode at work here. Is this a known issue or should I upload some debug logs to help diagnose this problem.
>>>>
>>>> Cheers
>>>> Glen
>>>> Gahenders@gmail.com
>>>
>>> Hi Glen,
>>> it seams I forgot to commit one patch about "Quote Of The Day" server
>>> in Nortel branch.
>>> I need to recover the old patch to rebase and commit it.
>>> In the mean time, here are some info for you to check.
>>>
>>> Using the official Nortel client and after the IPSec connection is
>>> established, a pop-up window is opened containing a message prepared
>>> by your network administrator.
>>> A QOTD server is responsible to send the content of the pop-up window
>>> to the client.
>>> Current vpnc-nortel does not decode the QOTD server info, does not
>>> contact the server, does not print the pop-up message.
>>> The QOTD server is inside the vpn protected network, so can only be
>>> accessed when IPSec connection is active.
>>>
>>> Network administrator can instruct the concentrator to check the
>>> version of the client.
>>> If version is older than expected, the concentrator replaces the QOTD
>>> message with an automatic error message reporting the lowest allowed
>>> version of the client.
>>> To print the error message, the concentrator have to complete the
>>> set-up of IPSec network, let client connect to QOTD server (inside the
>>> protected network), then drop the connection after 30 seconds timeout.
>>>
>>> I think this is the reason of your issue.
>>>
>>> Now, how to verify:
>>> run vpnc-nortel with flag "--debug 3" and perform a complete
>>> connection (that would be dropped in 30 seconds).
>>> Search inside the output the dumped packet with header:
>>> "S6.2 phase2_config receive modecfg"
>>> Inside this packet look for following lines:
>>> t.attributes.type: 400e (unknown)
>>> t.attributes.u.lots.length: 0004
>>> t.attributes.u.lots.data: 0a000115
>>> This is the info you need to connect to the QOTD server.
>>> The attribute type "400e" is QOTD server; following data reports IP
>>> address of the server.
>>> In my case it is 10.0.1.21, written in hex format.
>>>
>>> Now you have all info you need.
>>> Connect again to your server and be ready to use the 30 seconds of
>>> working connection to type in a shell (of course, replace with the IP
>>> address you get):
>>> telnet 10.0.1.21 17
>>> You will get the error message from the server.
>>>
>>> Once you know what is the client version that is expected, just tune
>>> the config file of your vpnc with proper field "Nortel Client ID" or
>>> try with command line flag "--nortel-client-id".
>>> You can print all the available codes with "vpnc --nortel-client-id list"
>>>
>>> Let me know if this works
>>>
>>> Best Regards
>>> Antonio Borneo
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

No luck on setting the client id. I get the same behaviour.

In actual fact the connection seems to be complete and working fine.
I am (briefly) able to access web-based resources that are hidden
being the VPN. Everything is OK until the connection drops somewhere
between 20 and 30 seconds in. I have run a packet trace on the
outside of the link and I do see an extra set of ISAKMP exchanges
right around the time I get disconnected. Unfortunately, I cannot see
what is going on during these exchanges since a) the packets are
encrypted and b) VPNC has since spawned off another process to work in
the background and I no longer see the debug output:

S7.9 main loop (receive and transmit ipsec packets)
[2012-07-01 19:02:22]
rx.key_cry: eda4825c 7c704275 fdb260f1 5cf01d30
rx.key_md:
418be725 a9cd4958 95d7b474 13353436 c23d11e8
tx.key_cry: 3cf3ce3c a82fd20d 20721d6d 17744ce7
tx.key_md:
531ac235 ea90d59b 94ead547 f831f003 3a62b325
remote -> local spi: 0x526b1793
local -> remote spi: 0xf3adbc51
VPNC started in background (pid: 8011)...

Is there a way to get the debug output of this background process?
Does that get redirected somewhere?

Cheers
Glen

On Sun, Jul 1, 2012 at 6:26 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:
> Hi Glen,
>
> I'm putting the mailing list in copy, since other users of vpnc-nortel
> could face same issue.
>
> My experience is that the accept/decline button acts on client only.
> No message is sent back to the server.
> The QOTD server just provides fixed reply to any telnet session and
> close the connection at the end of the message.
>
> Try to set a higher value for "--nortel-client-id". Default is 10 or "V04_15".
> The maximum value 65535 "VEXTRA" is used by the Linux client
> cvc_linux, but I'm not sure can work with every Nortel concentrator.
>
> Best Regards,
> Antonio Borneo
>
> On Sun, Jul 1, 2012 at 12:01 PM, Glen Henderson <gahenders@gmail.com> wrote:
>> After thinking it over, I realize that clicking the accept button may
>> not send anything on the network. The "accept/decline" button in the
>> Windows client may simply terminate the connection at the client end.
>> There may not be anything at the server end waiting for a formal
>> 'accept' of the AUP. If that is the case, I am back to trying to
>> figure out why my connection is terminating after a brief period of
>> connectivity (around 30 secs). I am assuming that since I am getting
>> the AUP message from the QOTD, everything is OK from the server's
>> perspective.
>>
>> I have traced the successful windows packet exchanges and the only
>> unusual things I see after the QOTD exchange are:
>>
>> 1. an IGMPv3 membership report
>> 2. Some NBNS multi-home registration
>>
>> That is about it. From the system log it appears that the connection
>> is terminated by the peer.
>>
>>
>> On Sat, Jun 30, 2012 at 9:36 PM, Glen Henderson <gahenders@gmail.com> wrote:
>>> You are definitely sending me on the right track. By querying that
>>> QOTD server I received the typical "acceptable use policy" message
>>> that I see presented to me when I connect using my Windows-based
>>> Nortel client. After connecting using the Windows Nortel client a
>>> dialog box with "Accept" or "Close" options is presented, implying
>>> that I need to send a message somewhere to indicate that I accept the
>>> AUP. When I telneted to the QOTD server, the AUP message was printed
>>> out and then the telnet session closed.
>>>
>>> Do you have any insights on where I would send a "I accept" message in
>>> such a scenario? I am assuming that since the Nortel VPN does not get
>>> the "I accept" message it is dropping my connection.
>>>
>>> This is significant progress though. I appreciate the help.
>>>
>>> Cheers
>>> Glen
>>>
>>> On Sat, Jun 30, 2012 at 7:40 PM, Antonio Borneo
>>> <borneo.antonio@gmail.com> wrote:
>>>> On Sun, Jul 1, 2012 at 4:49 AM, Glen Henderson <gahenders@gmail.com> wrote:
>>>>>
>>>>> I have seen this issue referenced before but I have not yet come across a resolution. I am using vpnc version 517 on Mac connecting to a Nortel VPN using token based authentication in nortel-udp NAT mode. I am able to connect and ping remote resources but after 30 seconds or so my session is disconnected. I saw mention a while back that there may be an unsupported NAT mode at work here. Is this a known issue or should I upload some debug logs to help diagnose this problem.
>>>>>
>>>>> Cheers
>>>>> Glen
>>>>> Gahenders@gmail.com
>>>>
>>>> Hi Glen,
>>>> it seams I forgot to commit one patch about "Quote Of The Day" server
>>>> in Nortel branch.
>>>> I need to recover the old patch to rebase and commit it.
>>>> In the mean time, here are some info for you to check.
>>>>
>>>> Using the official Nortel client and after the IPSec connection is
>>>> established, a pop-up window is opened containing a message prepared
>>>> by your network administrator.
>>>> A QOTD server is responsible to send the content of the pop-up window
>>>> to the client.
>>>> Current vpnc-nortel does not decode the QOTD server info, does not
>>>> contact the server, does not print the pop-up message.
>>>> The QOTD server is inside the vpn protected network, so can only be
>>>> accessed when IPSec connection is active.
>>>>
>>>> Network administrator can instruct the concentrator to check the
>>>> version of the client.
>>>> If version is older than expected, the concentrator replaces the QOTD
>>>> message with an automatic error message reporting the lowest allowed
>>>> version of the client.
>>>> To print the error message, the concentrator have to complete the
>>>> set-up of IPSec network, let client connect to QOTD server (inside the
>>>> protected network), then drop the connection after 30 seconds timeout.
>>>>
>>>> I think this is the reason of your issue.
>>>>
>>>> Now, how to verify:
>>>> run vpnc-nortel with flag "--debug 3" and perform a complete
>>>> connection (that would be dropped in 30 seconds).
>>>> Search inside the output the dumped packet with header:
>>>> "S6.2 phase2_config receive modecfg"
>>>> Inside this packet look for following lines:
>>>> t.attributes.type: 400e (unknown)
>>>> t.attributes.u.lots.length: 0004
>>>> t.attributes.u.lots.data: 0a000115
>>>> This is the info you need to connect to the QOTD server.
>>>> The attribute type "400e" is QOTD server; following data reports IP
>>>> address of the server.
>>>> In my case it is 10.0.1.21, written in hex format.
>>>>
>>>> Now you have all info you need.
>>>> Connect again to your server and be ready to use the 30 seconds of
>>>> working connection to type in a shell (of course, replace with the IP
>>>> address you get):
>>>> telnet 10.0.1.21 17
>>>> You will get the error message from the server.
>>>>
>>>> Once you know what is the client version that is expected, just tune
>>>> the config file of your vpnc with proper field "Nortel Client ID" or
>>>> try with command line flag "--nortel-client-id".
>>>> You can print all the available codes with "vpnc --nortel-client-id list"
>>>>
>>>> Let me know if this works
>>>>
>>>> Best Regards
>>>> Antonio Borneo
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

I had a similar problem but it wasn't related to the QOTD, if I commented
out the NAT Traversal Mode so it didn't select nortel-udp and instead went
with the default it worked fine for me. The customer whose VPN I am using
had upgraded their VPN and while it had worked fine before it stopped
working until I made that change. Here's my full configuration file:

IPSec gateway xxx.xxx.xxx.xxx
IPSec ID xxxxxx
IPSec secret xxxxxx
Xauth username xxxxxxx
IKE Authmode PIN-token
Xauth PIN XXXX
#NAT Traversal Mode nortel-udp
Vendor nortel
Perfect Forward Secrecy dh5
IKE DH Group dh5
#Nortel Client ID 27

Gerald

On Sun, Jul 1, 2012 at 7:11 PM, Glen Henderson <gahenders@gmail.com> wrote:

> No luck on setting the client id. I get the same behaviour.
>
> In actual fact the connection seems to be complete and working fine.
> I am (briefly) able to access web-based resources that are hidden
> being the VPN. Everything is OK until the connection drops somewhere
> between 20 and 30 seconds in. I have run a packet trace on the
> outside of the link and I do see an extra set of ISAKMP exchanges
> right around the time I get disconnected. Unfortunately, I cannot see
> what is going on during these exchanges since a) the packets are
> encrypted and b) VPNC has since spawned off another process to work in
> the background and I no longer see the debug output:
>
> S7.9 main loop (receive and transmit ipsec packets)
> [2012-07-01 19:02:22]
> rx.key_cry: eda4825c 7c704275 fdb260f1 5cf01d30
> rx.key_md:
> 418be725 a9cd4958 95d7b474 13353436 c23d11e8
> tx.key_cry: 3cf3ce3c a82fd20d 20721d6d 17744ce7
> tx.key_md:
> 531ac235 ea90d59b 94ead547 f831f003 3a62b325
> remote -> local spi: 0x526b1793
> local -> remote spi: 0xf3adbc51
> VPNC started in background (pid: 8011)...
>
> Is there a way to get the debug output of this background process?
> Does that get redirected somewhere?
>
> Cheers
> Glen
>
> On Sun, Jul 1, 2012 at 6:26 AM, Antonio Borneo <borneo.antonio@gmail.com>
> wrote:
> > Hi Glen,
> >
> > I'm putting the mailing list in copy, since other users of vpnc-nortel
> > could face same issue.
> >
> > My experience is that the accept/decline button acts on client only.
> > No message is sent back to the server.
> > The QOTD server just provides fixed reply to any telnet session and
> > close the connection at the end of the message.
> >
> > Try to set a higher value for "--nortel-client-id". Default is 10 or
> "V04_15".
> > The maximum value 65535 "VEXTRA" is used by the Linux client
> > cvc_linux, but I'm not sure can work with every Nortel concentrator.
> >
> > Best Regards,
> > Antonio Borneo
> >
> > On Sun, Jul 1, 2012 at 12:01 PM, Glen Henderson <gahenders@gmail.com>
> wrote:
> >> After thinking it over, I realize that clicking the accept button may
> >> not send anything on the network. The "accept/decline" button in the
> >> Windows client may simply terminate the connection at the client end.
> >> There may not be anything at the server end waiting for a formal
> >> 'accept' of the AUP. If that is the case, I am back to trying to
> >> figure out why my connection is terminating after a brief period of
> >> connectivity (around 30 secs). I am assuming that since I am getting
> >> the AUP message from the QOTD, everything is OK from the server's
> >> perspective.
> >>
> >> I have traced the successful windows packet exchanges and the only
> >> unusual things I see after the QOTD exchange are:
> >>
> >> 1. an IGMPv3 membership report
> >> 2. Some NBNS multi-home registration
> >>
> >> That is about it. From the system log it appears that the connection
> >> is terminated by the peer.
> >>
> >>
> >> On Sat, Jun 30, 2012 at 9:36 PM, Glen Henderson <gahenders@gmail.com>
> wrote:
> >>> You are definitely sending me on the right track. By querying that
> >>> QOTD server I received the typical "acceptable use policy" message
> >>> that I see presented to me when I connect using my Windows-based
> >>> Nortel client. After connecting using the Windows Nortel client a
> >>> dialog box with "Accept" or "Close" options is presented, implying
> >>> that I need to send a message somewhere to indicate that I accept the
> >>> AUP. When I telneted to the QOTD server, the AUP message was printed
> >>> out and then the telnet session closed.
> >>>
> >>> Do you have any insights on where I would send a "I accept" message in
> >>> such a scenario? I am assuming that since the Nortel VPN does not get
> >>> the "I accept" message it is dropping my connection.
> >>>
> >>> This is significant progress though. I appreciate the help.
> >>>
> >>> Cheers
> >>> Glen
> >>>
> >>> On Sat, Jun 30, 2012 at 7:40 PM, Antonio Borneo
> >>> <borneo.antonio@gmail.com> wrote:
> >>>> On Sun, Jul 1, 2012 at 4:49 AM, Glen Henderson <gahenders@gmail.com>
> wrote:
> >>>>>
> >>>>> I have seen this issue referenced before but I have not yet come
> across a resolution. I am using vpnc version 517 on Mac connecting to a
> Nortel VPN using token based authentication in nortel-udp NAT mode. I am
> able to connect and ping remote resources but after 30 seconds or so my
> session is disconnected. I saw mention a while back that there may be an
> unsupported NAT mode at work here. Is this a known issue or should I
> upload some debug logs to help diagnose this problem.
> >>>>>
> >>>>> Cheers
> >>>>> Glen
> >>>>> Gahenders@gmail.com
> >>>>
> >>>> Hi Glen,
> >>>> it seams I forgot to commit one patch about "Quote Of The Day" server
> >>>> in Nortel branch.
> >>>> I need to recover the old patch to rebase and commit it.
> >>>> In the mean time, here are some info for you to check.
> >>>>
> >>>> Using the official Nortel client and after the IPSec connection is
> >>>> established, a pop-up window is opened containing a message prepared
> >>>> by your network administrator.
> >>>> A QOTD server is responsible to send the content of the pop-up window
> >>>> to the client.
> >>>> Current vpnc-nortel does not decode the QOTD server info, does not
> >>>> contact the server, does not print the pop-up message.
> >>>> The QOTD server is inside the vpn protected network, so can only be
> >>>> accessed when IPSec connection is active.
> >>>>
> >>>> Network administrator can instruct the concentrator to check the
> >>>> version of the client.
> >>>> If version is older than expected, the concentrator replaces the QOTD
> >>>> message with an automatic error message reporting the lowest allowed
> >>>> version of the client.
> >>>> To print the error message, the concentrator have to complete the
> >>>> set-up of IPSec network, let client connect to QOTD server (inside the
> >>>> protected network), then drop the connection after 30 seconds timeout.
> >>>>
> >>>> I think this is the reason of your issue.
> >>>>
> >>>> Now, how to verify:
> >>>> run vpnc-nortel with flag "--debug 3" and perform a complete
> >>>> connection (that would be dropped in 30 seconds).
> >>>> Search inside the output the dumped packet with header:
> >>>> "S6.2 phase2_config receive modecfg"
> >>>> Inside this packet look for following lines:
> >>>> t.attributes.type: 400e (unknown)
> >>>> t.attributes.u.lots.length: 0004
> >>>> t.attributes.u.lots.data: 0a000115
> >>>> This is the info you need to connect to the QOTD server.
> >>>> The attribute type "400e" is QOTD server; following data reports IP
> >>>> address of the server.
> >>>> In my case it is 10.0.1.21, written in hex format.
> >>>>
> >>>> Now you have all info you need.
> >>>> Connect again to your server and be ready to use the 30 seconds of
> >>>> working connection to type in a shell (of course, replace with the IP
> >>>> address you get):
> >>>> telnet 10.0.1.21 17
> >>>> You will get the error message from the server.
> >>>>
> >>>> Once you know what is the client version that is expected, just tune
> >>>> the config file of your vpnc with proper field "Nortel Client ID" or
> >>>> try with command line flag "--nortel-client-id".
> >>>> You can print all the available codes with "vpnc --nortel-client-id
> list"
> >>>>
> >>>> Let me know if this works
> >>>>
> >>>> Best Regards
> >>>> Antonio Borneo
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>

Interesting. Which version were you using? When I run your
configuration under 517 I get:
./vpnc: Vendor nortel only accepts nat traversal modes: none nortel-udp
defaults to "none"

and the connection fails with:

do_phase2: S7.7 QM_packet3 sent - run script
[2012-07-01 19:45:54]
generating 52 bytes keymat (cnt=3)
generating 52 bytes keymat (cnt=3)

S7 setup_link (phase 2 + main_loop)
[2012-07-01 19:45:54]

S7.0 run interface setup script
[2012-07-01 19:45:54]
add host XXX.XXX.XXX.XXX: gateway XXX.XXX.XXX.XXX
add net XXX.XXX.XXX.XXX: gateway XXX.XXX.XXX.XXX
delete net default: gateway XXX.XXX.XXX.XXX
add net default: gateway XXX.XXX.XXX.XXX

S7.8 setup ipsec tunnel
[2012-07-01 19:45:54]
delete net default: gateway XXX.XXX.XXX.XXX
tun0
add net default: gateway XXX.XXX.XXX.XXX
delete host XXX.XXX.XXX.XXX: gateway XXX.XXX.XXX.XXX
tun0
Couldn't open socket of ESP. Maybe something registered ESP already.
Please try '--natt-mode force-natt' or disable whatever is using ESP.
socket(PF_INET, SOCK_RAW, IPPROTO_ESP): Protocol wrong type for socket


On Sun, Jul 1, 2012 at 7:18 PM, Gerald Nunn <gnunn@gexperts.com> wrote:
> I had a similar problem but it wasn't related to the QOTD, if I commented
> out the NAT Traversal Mode so it didn't select nortel-udp and instead went
> with the default it worked fine for me. The customer whose VPN I am using
> had upgraded their VPN and while it had worked fine before it stopped
> working until I made that change. Here's my full configuration file:
>
> IPSec gateway xxx.xxx.xxx.xxx
> IPSec ID xxxxxx
> IPSec secret xxxxxx
> Xauth username xxxxxxx
> IKE Authmode PIN-token
> Xauth PIN XXXX
> #NAT Traversal Mode nortel-udp
> Vendor nortel
> Perfect Forward Secrecy dh5
> IKE DH Group dh5
> #Nortel Client ID 27
>
> Gerald
>
> On Sun, Jul 1, 2012 at 7:11 PM, Glen Henderson <gahenders@gmail.com> wrote:
>>
>> No luck on setting the client id. I get the same behaviour.
>>
>> In actual fact the connection seems to be complete and working fine.
>> I am (briefly) able to access web-based resources that are hidden
>> being the VPN. Everything is OK until the connection drops somewhere
>> between 20 and 30 seconds in. I have run a packet trace on the
>> outside of the link and I do see an extra set of ISAKMP exchanges
>> right around the time I get disconnected. Unfortunately, I cannot see
>> what is going on during these exchanges since a) the packets are
>> encrypted and b) VPNC has since spawned off another process to work in
>> the background and I no longer see the debug output:
>>
>> S7.9 main loop (receive and transmit ipsec packets)
>> [2012-07-01 19:02:22]
>> rx.key_cry: eda4825c 7c704275 fdb260f1 5cf01d30
>> rx.key_md:
>> 418be725 a9cd4958 95d7b474 13353436 c23d11e8
>> tx.key_cry: 3cf3ce3c a82fd20d 20721d6d 17744ce7
>> tx.key_md:
>> 531ac235 ea90d59b 94ead547 f831f003 3a62b325
>> remote -> local spi: 0x526b1793
>> local -> remote spi: 0xf3adbc51
>> VPNC started in background (pid: 8011)...
>>
>> Is there a way to get the debug output of this background process?
>> Does that get redirected somewhere?
>>
>> Cheers
>> Glen
>>
>> On Sun, Jul 1, 2012 at 6:26 AM, Antonio Borneo <borneo.antonio@gmail.com>
>> wrote:
>> > Hi Glen,
>> >
>> > I'm putting the mailing list in copy, since other users of vpnc-nortel
>> > could face same issue.
>> >
>> > My experience is that the accept/decline button acts on client only.
>> > No message is sent back to the server.
>> > The QOTD server just provides fixed reply to any telnet session and
>> > close the connection at the end of the message.
>> >
>> > Try to set a higher value for "--nortel-client-id". Default is 10 or
>> > "V04_15".
>> > The maximum value 65535 "VEXTRA" is used by the Linux client
>> > cvc_linux, but I'm not sure can work with every Nortel concentrator.
>> >
>> > Best Regards,
>> > Antonio Borneo
>> >
>> > On Sun, Jul 1, 2012 at 12:01 PM, Glen Henderson <gahenders@gmail.com>
>> > wrote:
>> >> After thinking it over, I realize that clicking the accept button may
>> >> not send anything on the network. The "accept/decline" button in the
>> >> Windows client may simply terminate the connection at the client end.
>> >> There may not be anything at the server end waiting for a formal
>> >> 'accept' of the AUP. If that is the case, I am back to trying to
>> >> figure out why my connection is terminating after a brief period of
>> >> connectivity (around 30 secs). I am assuming that since I am getting
>> >> the AUP message from the QOTD, everything is OK from the server's
>> >> perspective.
>> >>
>> >> I have traced the successful windows packet exchanges and the only
>> >> unusual things I see after the QOTD exchange are:
>> >>
>> >> 1. an IGMPv3 membership report
>> >> 2. Some NBNS multi-home registration
>> >>
>> >> That is about it. From the system log it appears that the connection
>> >> is terminated by the peer.
>> >>
>> >>
>> >> On Sat, Jun 30, 2012 at 9:36 PM, Glen Henderson <gahenders@gmail.com>
>> >> wrote:
>> >>> You are definitely sending me on the right track. By querying that
>> >>> QOTD server I received the typical "acceptable use policy" message
>> >>> that I see presented to me when I connect using my Windows-based
>> >>> Nortel client. After connecting using the Windows Nortel client a
>> >>> dialog box with "Accept" or "Close" options is presented, implying
>> >>> that I need to send a message somewhere to indicate that I accept the
>> >>> AUP. When I telneted to the QOTD server, the AUP message was printed
>> >>> out and then the telnet session closed.
>> >>>
>> >>> Do you have any insights on where I would send a "I accept" message in
>> >>> such a scenario? I am assuming that since the Nortel VPN does not get
>> >>> the "I accept" message it is dropping my connection.
>> >>>
>> >>> This is significant progress though. I appreciate the help.
>> >>>
>> >>> Cheers
>> >>> Glen
>> >>>
>> >>> On Sat, Jun 30, 2012 at 7:40 PM, Antonio Borneo
>> >>> <borneo.antonio@gmail.com> wrote:
>> >>>> On Sun, Jul 1, 2012 at 4:49 AM, Glen Henderson <gahenders@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> I have seen this issue referenced before but I have not yet come
>> >>>>> across a resolution. I am using vpnc version 517 on Mac connecting to a
>> >>>>> Nortel VPN using token based authentication in nortel-udp NAT mode. I am
>> >>>>> able to connect and ping remote resources but after 30 seconds or so my
>> >>>>> session is disconnected. I saw mention a while back that there may be an
>> >>>>> unsupported NAT mode at work here. Is this a known issue or should I upload
>> >>>>> some debug logs to help diagnose this problem.
>> >>>>>
>> >>>>> Cheers
>> >>>>> Glen
>> >>>>> Gahenders@gmail.com
>> >>>>
>> >>>> Hi Glen,
>> >>>> it seams I forgot to commit one patch about "Quote Of The Day" server
>> >>>> in Nortel branch.
>> >>>> I need to recover the old patch to rebase and commit it.
>> >>>> In the mean time, here are some info for you to check.
>> >>>>
>> >>>> Using the official Nortel client and after the IPSec connection is
>> >>>> established, a pop-up window is opened containing a message prepared
>> >>>> by your network administrator.
>> >>>> A QOTD server is responsible to send the content of the pop-up window
>> >>>> to the client.
>> >>>> Current vpnc-nortel does not decode the QOTD server info, does not
>> >>>> contact the server, does not print the pop-up message.
>> >>>> The QOTD server is inside the vpn protected network, so can only be
>> >>>> accessed when IPSec connection is active.
>> >>>>
>> >>>> Network administrator can instruct the concentrator to check the
>> >>>> version of the client.
>> >>>> If version is older than expected, the concentrator replaces the QOTD
>> >>>> message with an automatic error message reporting the lowest allowed
>> >>>> version of the client.
>> >>>> To print the error message, the concentrator have to complete the
>> >>>> set-up of IPSec network, let client connect to QOTD server (inside
>> >>>> the
>> >>>> protected network), then drop the connection after 30 seconds
>> >>>> timeout.
>> >>>>
>> >>>> I think this is the reason of your issue.
>> >>>>
>> >>>> Now, how to verify:
>> >>>> run vpnc-nortel with flag "--debug 3" and perform a complete
>> >>>> connection (that would be dropped in 30 seconds).
>> >>>> Search inside the output the dumped packet with header:
>> >>>> "S6.2 phase2_config receive modecfg"
>> >>>> Inside this packet look for following lines:
>> >>>> t.attributes.type: 400e (unknown)
>> >>>> t.attributes.u.lots.length: 0004
>> >>>> t.attributes.u.lots.data: 0a000115
>> >>>> This is the info you need to connect to the QOTD server.
>> >>>> The attribute type "400e" is QOTD server; following data reports IP
>> >>>> address of the server.
>> >>>> In my case it is 10.0.1.21, written in hex format.
>> >>>>
>> >>>> Now you have all info you need.
>> >>>> Connect again to your server and be ready to use the 30 seconds of
>> >>>> working connection to type in a shell (of course, replace with the IP
>> >>>> address you get):
>> >>>> telnet 10.0.1.21 17
>> >>>> You will get the error message from the server.
>> >>>>
>> >>>> Once you know what is the client version that is expected, just tune
>> >>>> the config file of your vpnc with proper field "Nortel Client ID" or
>> >>>> try with command line flag "--nortel-client-id".
>> >>>> You can print all the available codes with "vpnc --nortel-client-id
>> >>>> list"
>> >>>>
>> >>>> Let me know if this works
>> >>>>
>> >>>> Best Regards
>> >>>> Antonio Borneo
>> _______________________________________________
>> vpnc-devel mailing list
>> vpnc-devel@unix-ag.uni-kl.de
>> 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@unix-ag.uni-kl.de
> 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@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

OK I seem to be caught between a rock and a hard place. If I use
version 464 with Gerald's configuration, my vpnc background process
stays up but my Nortel server does not like the NAT mode and I am
unable to connect to anything in my VPN's network. If I use a more
recent version of VPNC (e.g. 517) Gerald's configuration no longer
works since 'kernel ipsec' is no not a valid entry and I must specify
the NAT Traversal mode to be None or nortel-udp. Under Gerald's
configuration since the Nat mode is not specified, vpnc defaults to
None which generates on connect the following message:

Couldn't open socket of ESP. Maybe something registered ESP already.
Please try '--natt-mode force-natt' or disable whatever is using ESP.
socket(PF_INET, SOCK_RAW, IPPROTO_ESP): Protocol wrong type for socket

The ideal situation is to use version 517 with nortel-udp mode, but
that is the configuration that connects (successfully) but disconnects
after a brief period. This brief period is closer to 20 seconds which
puts it right in line with the default ISAKMP NAT keepalive value (for
Cisco anyway.. not sure what is it for Nortel)

Could VPNC be improperly processing keepalives? Crazy theory?
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

On Mon, Jul 2, 2012 at 7:11 AM, Glen Henderson <gahenders@gmail.com> wrote:
> ...
> VPNC started in background (pid: 8011)...
>
> Is there a way to get the debug output of this background process?

Yes, you can use command line "--no-detach" or "No Detach" in config file.
To save long dumps in a file, use the UNIX command "script" before
running vpnc, then exit from "script" when vpnc finishes.

Antonio
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Were you able to resolve this issue? I seem to be in a similar boat, but
not exactly sure if it is a QOTD or routing issue. I am using version 517
with the following configuration:

IPSec gateway xxxx.xxx.xxx
IPSec ID xxxx
IPSec secret xxxxx
Xauth username xxxx
IKE Authmode PIN-token
Xauth PIN xxxx
Vendor nortel
Perfect Forward Secrecy dh5

After entering the SecurID code (software), vpnc seems to connect and
authenticate correctly then continues in the background. At this point I
cannot connect to any servers on the company network, even the QOTD server
IP address given in the vpnc debug log.

Using the Windows client, after successfully authenticating it will bring
up a dialog with and Accept/Decline button. Until the Accept button is
clicked on, I cannot connect to any servers on the network. So it seems
that selecting the Accept button is enabling connectivity (routing?). If a
button on the Windows client dialog is not clicked within 30s, the connect
is terminated, whereas vpnc never seems to terminate the connection.

Ideas? What debug info would help further identify the problem?

-Jim

On Sun, Jul 1, 2012 at 11:30 PM, Glen Henderson <gahenders@gmail.com> wrote:

> OK I seem to be caught between a rock and a hard place. If I use
> version 464 with Gerald's configuration, my vpnc background process
> stays up but my Nortel server does not like the NAT mode and I am
> unable to connect to anything in my VPN's network. If I use a more
> recent version of VPNC (e.g. 517) Gerald's configuration no longer
> works since 'kernel ipsec' is no not a valid entry and I must specify
> the NAT Traversal mode to be None or nortel-udp. Under Gerald's
> configuration since the Nat mode is not specified, vpnc defaults to
> None which generates on connect the following message:
>
> Couldn't open socket of ESP. Maybe something registered ESP already.
> Please try '--natt-mode force-natt' or disable whatever is using ESP.
> socket(PF_INET, SOCK_RAW, IPPROTO_ESP): Protocol wrong type for socket
>
> The ideal situation is to use version 517 with nortel-udp mode, but
> that is the configuration that connects (successfully) but disconnects
> after a brief period. This brief period is closer to 20 seconds which
> puts it right in line with the default ISAKMP NAT keepalive value (for
> Cisco anyway.. not sure what is it for Nortel)
>
> Could VPNC be improperly processing keepalives? Crazy theory?
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>

Sadly no. I was not able to get this going (yet). After a few hours of playing with it one night I managed to kill my company's nortel VPN. They had to restart it and I thought it best to lay low for a while.

Unlike your experience, I am definitely able to connect temporarily and access resources like the qotd server and my updated routing table looks to be correct. After I am disconnected (after 30 seconds or so) everything stops. Looks like I am being disconnected from the remote side but it is hard to say for sure.

Cheers
Glen

On 2012-07-06, at 11:22 AM, Jim Shepherd <jeshep@gmail.com> wrote:

> Were you able to resolve this issue? I seem to be in a similar boat, but not exactly sure if it is a QOTD or routing issue. I am using version 517 with the following configuration:
>
> IPSec gateway xxxx.xxx.xxx
> IPSec ID xxxx
> IPSec secret xxxxx
> Xauth username xxxx
> IKE Authmode PIN-token
> Xauth PIN xxxx
> Vendor nortel
> Perfect Forward Secrecy dh5
>
> After entering the SecurID code (software), vpnc seems to connect and authenticate correctly then continues in the background. At this point I cannot connect to any servers on the company network, even the QOTD server IP address given in the vpnc debug log.
>
> Using the Windows client, after successfully authenticating it will bring up a dialog with and Accept/Decline button. Until the Accept button is clicked on, I cannot connect to any servers on the network. So it seems that selecting the Accept button is enabling connectivity (routing?). If a button on the Windows client dialog is not clicked within 30s, the connect is terminated, whereas vpnc never seems to terminate the connection.
>
> Ideas? What debug info would help further identify the problem?
>
> -Jim
>
> On Sun, Jul 1, 2012 at 11:30 PM, Glen Henderson <gahenders@gmail.com> wrote:
> OK I seem to be caught between a rock and a hard place. If I use
> version 464 with Gerald's configuration, my vpnc background process
> stays up but my Nortel server does not like the NAT mode and I am
> unable to connect to anything in my VPN's network. If I use a more
> recent version of VPNC (e.g. 517) Gerald's configuration no longer
> works since 'kernel ipsec' is no not a valid entry and I must specify
> the NAT Traversal mode to be None or nortel-udp. Under Gerald's
> configuration since the Nat mode is not specified, vpnc defaults to
> None which generates on connect the following message:
>
> Couldn't open socket of ESP. Maybe something registered ESP already.
> Please try '--natt-mode force-natt' or disable whatever is using ESP.
> socket(PF_INET, SOCK_RAW, IPPROTO_ESP): Protocol wrong type for socket
>
> The ideal situation is to use version 517 with nortel-udp mode, but
> that is the configuration that connects (successfully) but disconnects
> after a brief period. This brief period is closer to 20 seconds which
> puts it right in line with the default ISAKMP NAT keepalive value (for
> Cisco anyway.. not sure what is it for Nortel)
>
> Could VPNC be improperly processing keepalives? Crazy theory?
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> 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@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/

Hi Jim,

On Fri, Jul 6, 2012 at 11:22 PM, Jim Shepherd <jeshep@gmail.com> wrote:
> Were you able to resolve this issue? I seem to be in a similar boat, but not
> exactly sure if it is a QOTD or routing issue. I am using version 517 with
> the following configuration:
>
> IPSec gateway xxxx.xxx.xxx
> IPSec ID xxxx
> IPSec secret xxxxx
> Xauth username xxxx
> IKE Authmode PIN-token
> Xauth PIN xxxx
> Vendor nortel
> Perfect Forward Secrecy dh5
>
> After entering the SecurID code (software), vpnc seems to connect and
> authenticate correctly then continues in the background. At this point I
> cannot connect to any servers on the company network, even the QOTD server
> IP address given in the vpnc debug log.

since vpnc goes background, this should confirm it correctly authenticates.

If you cannot communicate with company network, this could depends on
many factors:
a) wrong routing table
b) local firewall (iptables) configuration
c) modem/router/provider that stops ESP packets

I would suggest you for b) to temporarily disable the firewall and for
c) to switch to UDP packets using NATT by adding following line to the
configuration file
NAT Traversal Mode nortel-udp

For a) I would suggest you to carefully check routing tables before
and after vpnc launch.

> Using the Windows client, after successfully authenticating it will bring up
> a dialog with and Accept/Decline button. Until the Accept button is clicked
> on, I cannot connect to any servers on the network. So it seems that
> selecting the Accept button is enabling connectivity (routing?). If a button
> on the Windows client dialog is not clicked within 30s, the connect is
> terminated, whereas vpnc never seems to terminate the connection.

The dialog box seams fully managed by the Windows client.
Anyway, I have access to just few Nortel servers, so cannot be sure to
cover all possible cases.

Best Regards,
Antonio Borneo
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Thanks! Your suggestion of using the "NAT Traversal Mode nortel-udp"
configuration has helped. I can now communicate with some computers on the
network, but only for ~30s before the vpnc session is terminated.

I have the output from running "vpnc --debug 3 --no-detach" that might be
helpful as it shows several exchanges prior to termination. I'll send it
separately to your gmail address.

-Jim

On Thu, Jul 12, 2012 at 11:23 PM, Antonio Borneo
<borneo.antonio@gmail.com>wrote:

> Hi Jim,
>
> On Fri, Jul 6, 2012 at 11:22 PM, Jim Shepherd <jeshep@gmail.com> wrote:
> > Were you able to resolve this issue? I seem to be in a similar boat, but
> not
> > exactly sure if it is a QOTD or routing issue. I am using version 517
> with
> > the following configuration:
> >
> > IPSec gateway xxxx.xxx.xxx
> > IPSec ID xxxx
> > IPSec secret xxxxx
> > Xauth username xxxx
> > IKE Authmode PIN-token
> > Xauth PIN xxxx
> > Vendor nortel
> > Perfect Forward Secrecy dh5
> >
> > After entering the SecurID code (software), vpnc seems to connect and
> > authenticate correctly then continues in the background. At this point I
> > cannot connect to any servers on the company network, even the QOTD
> server
> > IP address given in the vpnc debug log.
>
> since vpnc goes background, this should confirm it correctly authenticates.
>
> If you cannot communicate with company network, this could depends on
> many factors:
> a) wrong routing table
> b) local firewall (iptables) configuration
> c) modem/router/provider that stops ESP packets
>
> I would suggest you for b) to temporarily disable the firewall and for
> c) to switch to UDP packets using NATT by adding following line to the
> configuration file
> NAT Traversal Mode nortel-udp
>
> For a) I would suggest you to carefully check routing tables before
> and after vpnc launch.
>
> > Using the Windows client, after successfully authenticating it will
> bring up
> > a dialog with and Accept/Decline button. Until the Accept button is
> clicked
> > on, I cannot connect to any servers on the network. So it seems that
> > selecting the Accept button is enabling connectivity (routing?). If a
> button
> > on the Windows client dialog is not clicked within 30s, the connect is
> > terminated, whereas vpnc never seems to terminate the connection.
>
> The dialog box seams fully managed by the Windows client.
> Anyway, I have access to just few Nortel servers, so cannot be sure to
> cover all possible cases.
>
> Best Regards,
> Antonio Borneo
>

On Fri, Jul 13, 2012 at 12:38 PM, Jim Shepherd <jeshep@gmail.com> wrote:
> Thanks! Your suggestion of using the "NAT Traversal Mode nortel-udp"
> configuration has helped. I can now communicate with some computers on the
> network, but only for ~30s before the vpnc session is terminated.

Ok, so issue was on ESP packets, dropped somewhere.
I use to have 2 configurations, with and without NATT. When I'm home I
choose no NATT since I get lower network latency and higher bandwidth,
but with public hotspot I'm forced to use NATT.

> I have the output from running "vpnc --debug 3 --no-detach" that might be
> helpful as it shows several exchanges prior to termination. I'll send it
> separately to your gmail address.

Received, but cannot find anything strange inside.
Try to connect to QOTD server during the 30 seconds. Probably you get
some valuable message.
From your log the command to connect to QOTD server should be
telnet 137.183.230.152 17

Best Regards
Antonio Borneo
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Good stuff. Jim and I are seeing essentially the same thing now. In my case, the qotd only gave my company's acceptable use policy and an advisory for people who do not have access to terminate their session. I am still wondering if hitting the accept button sends a message via the VPN, perhaps for audit purposes, to record that someone formally accepts the AUP. In the absence of this accept message, the VPN aborts the connection after a period of time. I wonder if this is documented in the nortel specs anywhere.

Cheers
Glen

On 2012-07-13, at 12:53 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:

> On Fri, Jul 13, 2012 at 12:38 PM, Jim Shepherd <jeshep@gmail.com> wrote:
>> Thanks! Your suggestion of using the "NAT Traversal Mode nortel-udp"
>> configuration has helped. I can now communicate with some computers on the
>> network, but only for ~30s before the vpnc session is terminated.
>
> Ok, so issue was on ESP packets, dropped somewhere.
> I use to have 2 configurations, with and without NATT. When I'm home I
> choose no NATT since I get lower network latency and higher bandwidth,
> but with public hotspot I'm forced to use NATT.
>
>> I have the output from running "vpnc --debug 3 --no-detach" that might be
>> helpful as it shows several exchanges prior to termination. I'll send it
>> separately to your gmail address.
>
> Received, but cannot find anything strange inside.
> Try to connect to QOTD server during the 30 seconds. Probably you get
> some valuable message.
> From your log the command to connect to QOTD server should be
> telnet 137.183.230.152 17
>
> Best Regards
> Antonio Borneo
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> 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@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Looks like "user did not acknowledge the banner" is a valid reason for nortel to disconnect your session.

http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/


On 2012-07-13, at 1:04 AM, Glen Henderson <gahenders@gmail.com> wrote:

> Good stuff. Jim and I are seeing essentially the same thing now. In my case, the qotd only gave my company's acceptable use policy and an advisory for people who do not have access to terminate their session. I am still wondering if hitting the accept button sends a message via the VPN, perhaps for audit purposes, to record that someone formally accepts the AUP. In the absence of this accept message, the VPN aborts the connection after a period of time. I wonder if this is documented in the nortel specs anywhere.
>
> Cheers
> Glen
>
> On 2012-07-13, at 12:53 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:
>
>> On Fri, Jul 13, 2012 at 12:38 PM, Jim Shepherd <jeshep@gmail.com> wrote:
>>> Thanks! Your suggestion of using the "NAT Traversal Mode nortel-udp"
>>> configuration has helped. I can now communicate with some computers on the
>>> network, but only for ~30s before the vpnc session is terminated.
>>
>> Ok, so issue was on ESP packets, dropped somewhere.
>> I use to have 2 configurations, with and without NATT. When I'm home I
>> choose no NATT since I get lower network latency and higher bandwidth,
>> but with public hotspot I'm forced to use NATT.
>>
>>> I have the output from running "vpnc --debug 3 --no-detach" that might be
>>> helpful as it shows several exchanges prior to termination. I'll send it
>>> separately to your gmail address.
>>
>> Received, but cannot find anything strange inside.
>> Try to connect to QOTD server during the 30 seconds. Probably you get
>> some valuable message.
>> From your log the command to connect to QOTD server should be
>> telnet 137.183.230.152 17
>>
>> Best Regards
>> Antonio Borneo
>> _______________________________________________
>> vpnc-devel mailing list
>> vpnc-devel@unix-ag.uni-kl.de
>> 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@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

On Fri, Jul 13, 2012 at 1:13 PM, Glen Henderson <gahenders@gmail.com> wrote:
> Looks like "user did not acknowledge the banner" is a valid reason for nortel to disconnect your session.
>
> http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/

Well spotted.
I did not tracked the acquisition of Nortel VPN from Avaya nor the
evolution of their family of products.

Seams something changed in the way banner is used.
Please check this document
http://downloads.avaya.com/css/P8/documents/100125135
and search the text "wi00666178"
The explanation of the bug wi00666178, fixed by this release of Avaya
client, explicitly mention user acknowledge of the banner.

From what Glen reports, he can connect to the MOTD server in the same
way of old clients.
We need to find the way client sends the acknowledge.

I never tried to use wireshark with Windows client. Is it able to
catch the traffic on the virtual interface (before encryption)?
If wireshark works, is it able to catch the TCP connection to QOTD
server port 17 and the following acknowledge packets?

Best Regards,
Antonio
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

A wireshark packet capture of a valid session would be the logical next step. I believe it is possible to capture off the VPN interface and thus get raw/unprotected packets. I will do some investigating and forward a captured session.

G.

On 2012-07-13, at 2:39 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:

> On Fri, Jul 13, 2012 at 1:13 PM, Glen Henderson <gahenders@gmail.com> wrote:
>> Looks like "user did not acknowledge the banner" is a valid reason for nortel to disconnect your session.
>>
>> http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/
>
> Well spotted.
> I did not tracked the acquisition of Nortel VPN from Avaya nor the
> evolution of their family of products.
>
> Seams something changed in the way banner is used.
> Please check this document
> http://downloads.avaya.com/css/P8/documents/100125135
> and search the text "wi00666178"
> The explanation of the bug wi00666178, fixed by this release of Avaya
> client, explicitly mention user acknowledge of the banner.
>
> From what Glen reports, he can connect to the MOTD server in the same
> way of old clients.
> We need to find the way client sends the acknowledge.
>
> I never tried to use wireshark with Windows client. Is it able to
> catch the traffic on the virtual interface (before encryption)?
> If wireshark works, is it able to catch the TCP connection to QOTD
> server port 17 and the following acknowledge packets?
>
> Best Regards,
> Antonio
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Any update on this issue? I have mutliple users reporting similar behavior...

Fabian
ChungwaSoft | Fabian Jäger | Founder & Software Engineer | main projects - Shimo, GeoTagr
contact | fabian.jaeger@chungwasoft.com | aim - fabian.jaeger@mac.com | twitter - dotGuru

Am 14.07.2012 um 05:38 schrieb Glen Henderson <gahenders@gmail.com>:

> A wireshark packet capture of a valid session would be the logical next step. I believe it is possible to capture off the VPN interface and thus get raw/unprotected packets. I will do some investigating and forward a captured session.
>
> G.
>
> On 2012-07-13, at 2:39 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:
>
>> On Fri, Jul 13, 2012 at 1:13 PM, Glen Henderson <gahenders@gmail.com> wrote:
>>> Looks like "user did not acknowledge the banner" is a valid reason for nortel to disconnect your session.
>>>
>>> http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/
>>
>> Well spotted.
>> I did not tracked the acquisition of Nortel VPN from Avaya nor the
>> evolution of their family of products.
>>
>> Seams something changed in the way banner is used.
>> Please check this document
>> http://downloads.avaya.com/css/P8/documents/100125135
>> and search the text "wi00666178"
>> The explanation of the bug wi00666178, fixed by this release of Avaya
>> client, explicitly mention user acknowledge of the banner.
>>
>> From what Glen reports, he can connect to the MOTD server in the same
>> way of old clients.
>> We need to find the way client sends the acknowledge.
>>
>> I never tried to use wireshark with Windows client. Is it able to
>> catch the traffic on the virtual interface (before encryption)?
>> If wireshark works, is it able to catch the TCP connection to QOTD
>> server port 17 and the following acknowledge packets?
>>
>> Best Regards,
>> Antonio
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>

Hi Fabian,

no updates.
I have access to only four Nortel servers, and all work fine with current vpnc.
My personal opinion is that the new behaviour is introduced in new
Avaya servers or is part of firmware update of existing servers.

If someone can provide me a temporarily account on servers that have
such issue, I could try to investigate.

Best Regards,
Antonio Borneo

On Fri, Sep 7, 2012 at 9:38 PM, "[ChungwaSoft] Fabian Jäger"
<fabian.jaeger@chungwasoft.com> wrote:
>
> Any update on this issue? I have mutliple users reporting similar
> behavior...
>
> Fabian
> ChungwaSoft | Fabian Jäger | Founder & Software Engineer | main projects -
> Shimo, GeoTagr
> contact | fabian.jaeger@chungwasoft.com | aim - fabian.jaeger@mac.com |
> twitter - dotGuru
>
> Am 14.07.2012 um 05:38 schrieb Glen Henderson <gahenders@gmail.com>:
>
> A wireshark packet capture of a valid session would be the logical next
> step. I believe it is possible to capture off the VPN interface and thus
> get raw/unprotected packets. I will do some investigating and forward a
> captured session.
>
> G.
>
> On 2012-07-13, at 2:39 AM, Antonio Borneo <borneo.antonio@gmail.com>
> wrote:
>
> On Fri, Jul 13, 2012 at 1:13 PM, Glen Henderson <gahenders@gmail.com>
> wrote:
>
> Looks like "user did not acknowledge the banner" is a valid reason for
> nortel to disconnect your session.
>
>
> http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/
>
>
> Well spotted.
> I did not tracked the acquisition of Nortel VPN from Avaya nor the
> evolution of their family of products.
>
> Seams something changed in the way banner is used.
> Please check this document
> http://downloads.avaya.com/css/P8/documents/100125135
> and search the text "wi00666178"
> The explanation of the bug wi00666178, fixed by this release of Avaya
> client, explicitly mention user acknowledge of the banner.
>
> From what Glen reports, he can connect to the MOTD server in the same
> way of old clients.
> We need to find the way client sends the acknowledge.
>
> I never tried to use wireshark with Windows client. Is it able to
> catch the traffic on the virtual interface (before encryption)?
> If wireshark works, is it able to catch the TCP connection to QOTD
> server port 17 and the following acknowledge packets?
>
> Best Regards,
> Antonio
>
> _______________________________________________
>
> vpnc-devel mailing list
> vpnc-devel@unix-ag.uni-kl.de
> 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@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

I only experienced this issue when running from Mac (snow leopard in my case). Eventually I ran up a window7 virtual machine inside VirtualBox and accessed my corporate VPN through the vm. Within w7 I used the AvayaVPN client. Since this was a basic W7 install (no domain join...no secret shenanigans that my company added to the corporately-provided laptop image to validate a VPN session) it proved that the issue is with vpnc or possibly the Mac network stack. A raw w7 install with the Avaya client works pretty much out of the box but the vpnc client under Mac with the same VPN parameters does not.

Cheers
Glen

On 2012-09-08, at 6:35 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:

> Hi Fabian,
>
> no updates.
> I have access to only four Nortel servers, and all work fine with current vpnc.
> My personal opinion is that the new behaviour is introduced in new
> Avaya servers or is part of firmware update of existing servers.
>
> If someone can provide me a temporarily account on servers that have
> such issue, I could try to investigate.
>
> Best Regards,
> Antonio Borneo
>
> On Fri, Sep 7, 2012 at 9:38 PM, "[ChungwaSoft] Fabian Jäger"
> <fabian.jaeger@chungwasoft.com> wrote:
>>
>> Any update on this issue? I have mutliple users reporting similar
>> behavior...
>>
>> Fabian
>> ChungwaSoft | Fabian Jäger | Founder & Software Engineer | main projects -
>> Shimo, GeoTagr
>> contact | fabian.jaeger@chungwasoft.com | aim - fabian.jaeger@mac.com |
>> twitter - dotGuru
>>
>> Am 14.07.2012 um 05:38 schrieb Glen Henderson <gahenders@gmail.com>:
>>
>> A wireshark packet capture of a valid session would be the logical next
>> step. I believe it is possible to capture off the VPN interface and thus
>> get raw/unprotected packets. I will do some investigating and forward a
>> captured session.
>>
>> G.
>>
>> On 2012-07-13, at 2:39 AM, Antonio Borneo <borneo.antonio@gmail.com>
>> wrote:
>>
>> On Fri, Jul 13, 2012 at 1:13 PM, Glen Henderson <gahenders@gmail.com>
>> wrote:
>>
>> Looks like "user did not acknowledge the banner" is a valid reason for
>> nortel to disconnect your session.
>>
>>
>> http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/
>>
>>
>> Well spotted.
>> I did not tracked the acquisition of Nortel VPN from Avaya nor the
>> evolution of their family of products.
>>
>> Seams something changed in the way banner is used.
>> Please check this document
>> http://downloads.avaya.com/css/P8/documents/100125135
>> and search the text "wi00666178"
>> The explanation of the bug wi00666178, fixed by this release of Avaya
>> client, explicitly mention user acknowledge of the banner.
>>
>> From what Glen reports, he can connect to the MOTD server in the same
>> way of old clients.
>> We need to find the way client sends the acknowledge.
>>
>> I never tried to use wireshark with Windows client. Is it able to
>> catch the traffic on the virtual interface (before encryption)?
>> If wireshark works, is it able to catch the TCP connection to QOTD
>> server port 17 and the following acknowledge packets?
>>
>> Best Regards,
>> Antonio
>>
>> _______________________________________________
>>
>> vpnc-devel mailing list
>> vpnc-devel@unix-ag.uni-kl.de
>> 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@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Hi Glen,

Nortel VPN products has been acquired by Avaya.
Avaya now distribute routers and VPN clients that apparently use some
kind of new feature during authentication.
This feature is not implemented in vpnc. As far as I know there is no
public documentation on this feature.

This is in line with what you see.
AvayaVPN on Windows works with no issues.
Vpnc, instead, does not implement the new feature and the server close
the connection after a timeout.

Without any documentation, the only way to fix the issue in vpnc is to
reverse-engineer the part of protocol responsible for this new "banner
acknowledge" feature.

I'm unable to do any step further, since I do not have access to any
server that implements this feature.

Best Regards,
Antonio Borneo


On Sun, Sep 9, 2012 at 12:02 AM, Glen Henderson <gahenders@gmail.com> wrote:
> I only experienced this issue when running from Mac (snow leopard in my case). Eventually I ran up a window7 virtual machine inside VirtualBox and accessed my corporate VPN through the vm. Within w7 I used the AvayaVPN client. Since this was a basic W7 install (no domain join...no secret shenanigans that my company added to the corporately-provided laptop image to validate a VPN session) it proved that the issue is with vpnc or possibly the Mac network stack. A raw w7 install with the Avaya client works pretty much out of the box but the vpnc client under Mac with the same VPN parameters does not.
>
> Cheers
> Glen
>
> On 2012-09-08, at 6:35 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:
>
>> Hi Fabian,
>>
>> no updates.
>> I have access to only four Nortel servers, and all work fine with current vpnc.
>> My personal opinion is that the new behaviour is introduced in new
>> Avaya servers or is part of firmware update of existing servers.
>>
>> If someone can provide me a temporarily account on servers that have
>> such issue, I could try to investigate.
>>
>> Best Regards,
>> Antonio Borneo
>>
>> On Fri, Sep 7, 2012 at 9:38 PM, "[ChungwaSoft] Fabian Jäger"
>> <fabian.jaeger@chungwasoft.com> wrote:
>>>
>>> Any update on this issue? I have mutliple users reporting similar
>>> behavior...
>>>
>>> Fabian
>>> ChungwaSoft | Fabian Jäger | Founder & Software Engineer | main projects -
>>> Shimo, GeoTagr
>>> contact | fabian.jaeger@chungwasoft.com | aim - fabian.jaeger@mac.com |
>>> twitter - dotGuru
>>>
>>> Am 14.07.2012 um 05:38 schrieb Glen Henderson <gahenders@gmail.com>:
>>>
>>> A wireshark packet capture of a valid session would be the logical next
>>> step. I believe it is possible to capture off the VPN interface and thus
>>> get raw/unprotected packets. I will do some investigating and forward a
>>> captured session.
>>>
>>> G.
>>>
>>> On 2012-07-13, at 2:39 AM, Antonio Borneo <borneo.antonio@gmail.com>
>>> wrote:
>>>
>>> On Fri, Jul 13, 2012 at 1:13 PM, Glen Henderson <gahenders@gmail.com>
>>> wrote:
>>>
>>> Looks like "user did not acknowledge the banner" is a valid reason for
>>> nortel to disconnect your session.
>>>
>>>
>>> http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/
>>>
>>>
>>> Well spotted.
>>> I did not tracked the acquisition of Nortel VPN from Avaya nor the
>>> evolution of their family of products.
>>>
>>> Seams something changed in the way banner is used.
>>> Please check this document
>>> http://downloads.avaya.com/css/P8/documents/100125135
>>> and search the text "wi00666178"
>>> The explanation of the bug wi00666178, fixed by this release of Avaya
>>> client, explicitly mention user acknowledge of the banner.
>>>
>>> From what Glen reports, he can connect to the MOTD server in the same
>>> way of old clients.
>>> We need to find the way client sends the acknowledge.
>>>
>>> I never tried to use wireshark with Windows client. Is it able to
>>> catch the traffic on the virtual interface (before encryption)?
>>> If wireshark works, is it able to catch the TCP connection to QOTD
>>> server port 17 and the following acknowledge packets?
>>>
>>> Best Regards,
>>> Antonio
>>>
>>> _______________________________________________
>>>
>>> vpnc-devel mailing list
>>> vpnc-devel@unix-ag.uni-kl.de
>>> 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@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Antonio,

While I cannot provide you direct access to our VPN servers, I can provide
vpnc and wireshark logs while attempting to connect to our VPN servers
using vpnc on linux as well as wireshark logs while successfully connecting
with the Avaya client from a Windows 7 virtual machine. I haven't been able
to figure out how to get wireshark to unencrypt the VPN packets, so I would
need some help configuring wireshark in order for those logs to be useful.
Just let me know how (if) I can be useful.

-Jim

On Mon, Sep 10, 2012 at 1:50 AM, Antonio Borneo <borneo.antonio@gmail.com>wrote:

> Hi Glen,
>
> Nortel VPN products has been acquired by Avaya.
> Avaya now distribute routers and VPN clients that apparently use some
> kind of new feature during authentication.
> This feature is not implemented in vpnc. As far as I know there is no
> public documentation on this feature.
>
> This is in line with what you see.
> AvayaVPN on Windows works with no issues.
> Vpnc, instead, does not implement the new feature and the server close
> the connection after a timeout.
>
> Without any documentation, the only way to fix the issue in vpnc is to
> reverse-engineer the part of protocol responsible for this new "banner
> acknowledge" feature.
>
> I'm unable to do any step further, since I do not have access to any
> server that implements this feature.
>
> Best Regards,
> Antonio Borneo
>
>
> On Sun, Sep 9, 2012 at 12:02 AM, Glen Henderson <gahenders@gmail.com>
> wrote:
> > I only experienced this issue when running from Mac (snow leopard in my
> case). Eventually I ran up a window7 virtual machine inside VirtualBox and
> accessed my corporate VPN through the vm. Within w7 I used the AvayaVPN
> client. Since this was a basic W7 install (no domain join...no secret
> shenanigans that my company added to the corporately-provided laptop image
> to validate a VPN session) it proved that the issue is with vpnc or
> possibly the Mac network stack. A raw w7 install with the Avaya client
> works pretty much out of the box but the vpnc client under Mac with the
> same VPN parameters does not.
> >
> > Cheers
> > Glen
> >
> > On 2012-09-08, at 6:35 AM, Antonio Borneo <borneo.antonio@gmail.com>
> wrote:
> >
> >> Hi Fabian,
> >>
> >> no updates.
> >> I have access to only four Nortel servers, and all work fine with
> current vpnc.
> >> My personal opinion is that the new behaviour is introduced in new
> >> Avaya servers or is part of firmware update of existing servers.
> >>
> >> If someone can provide me a temporarily account on servers that have
> >> such issue, I could try to investigate.
> >>
> >> Best Regards,
> >> Antonio Borneo
> >>
> >> On Fri, Sep 7, 2012 at 9:38 PM, "[ChungwaSoft] Fabian Jäger"
> >> <fabian.jaeger@chungwasoft.com> wrote:
> >>>
> >>> Any update on this issue? I have mutliple users reporting similar
> >>> behavior...
> >>>
> >>> Fabian
> >>> ChungwaSoft | Fabian Jäger | Founder & Software Engineer | main
> projects -
> >>> Shimo, GeoTagr
> >>> contact | fabian.jaeger@chungwasoft.com | aim - fabian.jaeger@mac.com|
> >>> twitter - dotGuru
> >>>
> >>> Am 14.07.2012 um 05:38 schrieb Glen Henderson <gahenders@gmail.com>:
> >>>
> >>> A wireshark packet capture of a valid session would be the logical next
> >>> step. I believe it is possible to capture off the VPN interface and
> thus
> >>> get raw/unprotected packets. I will do some investigating and forward
> a
> >>> captured session.
> >>>
> >>> G.
> >>>
> >>> On 2012-07-13, at 2:39 AM, Antonio Borneo <borneo.antonio@gmail.com>
> >>> wrote:
> >>>
> >>> On Fri, Jul 13, 2012 at 1:13 PM, Glen Henderson <gahenders@gmail.com>
> >>> wrote:
> >>>
> >>> Looks like "user did not acknowledge the banner" is a valid reason for
> >>> nortel to disconnect your session.
> >>>
> >>>
> >>>
> http://blog.michaelfmcnamara.com/2008/11/nortel-vpn-client-checking-for-banner-text/
> >>>
> >>>
> >>> Well spotted.
> >>> I did not tracked the acquisition of Nortel VPN from Avaya nor the
> >>> evolution of their family of products.
> >>>
> >>> Seams something changed in the way banner is used.
> >>> Please check this document
> >>> http://downloads.avaya.com/css/P8/documents/100125135
> >>> and search the text "wi00666178"
> >>> The explanation of the bug wi00666178, fixed by this release of Avaya
> >>> client, explicitly mention user acknowledge of the banner.
> >>>
> >>> From what Glen reports, he can connect to the MOTD server in the same
> >>> way of old clients.
> >>> We need to find the way client sends the acknowledge.
> >>>
> >>> I never tried to use wireshark with Windows client. Is it able to
> >>> catch the traffic on the virtual interface (before encryption)?
> >>> If wireshark works, is it able to catch the TCP connection to QOTD
> >>> server port 17 and the following acknowledge packets?
> >>>
> >>> Best Regards,
> >>> Antonio
> >>>
> >>> _______________________________________________
> >>>
> >>> vpnc-devel mailing list
> >>> vpnc-devel@unix-ag.uni-kl.de
> >>> 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@unix-ag.uni-kl.de
> https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/
>

Hello,

I am very new to using mailman, so apologies for anything lame from my
side. I still don't know if this will jump into correct thread.

I just wanted to share info, that I struggle the same VPN connection
as Antonio, 137,183.230.152. I don't think this client installs Avaya
hardware. On my Windows operating system, I run Nortel VPN and receive
exactly the same message as from telnet 137,183.230.152 17. Do You
know how to simulate a pressed Accept key in windowed nortel vpn
client?

So far me and my team-mate have connected to VPN but connection is
dropped after about 30 seconds.
Settings I use:
--vendor nortel
--nortel-client-id V04_65
--natt-mode nortel-udp
--dh dh1
--enable-1des
--auth-mode PIN-token
--udp-port 4500

Regards
Jakub
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Hi Jakub,

On Wed, Oct 31, 2012 at 7:28 AM, Jakub Pietkun <jpietkun@gmail.com> wrote:
> Hello,
>
> With the help of wirechark I have analyzed what's going during establishing
> a vpn connection on Windows. I see a 3-way handshake and further, a PUSH
> packet. And finally, when Accept button is pressed, it sends a packet with
> flags FIN,ACK and determined SEQ and ACK values to QOTD server. All those
> packets are exchanged with the IP of QOTD server.

These are very interesting observations.
So there is a handshake on QOTD server following press of "Accept" button.

> I cannot observe the same on Linux. In fact, in wireshark I cannot see tun
> interface and don't know how to make wireshark see it. In fact, I cannot see
> tun interface with command "ifconfig". I can observe network traffic only on
> eth0 interface.

You will not find the same sequence in Linux, since current vpnc does
not implement any connection with QOTD server.

The tun interface is normally created dynamically by vpnc at start,
and destroyed as soon as vpnc exit.
You can bypass this by creating a persistent tun interface with
command tunctl, e.g. "tunctl -n -t tun3", then start wireshark on it.
You also need to specify the persistent tun interface to vpnc, using
command line "--ifname tun3" or "Interface name tun3" in config file.

> What I tried is to send this packet to QOTD server with hping3 but it didn't
> help. Probably I have to simulate all the "handshake" sequence.

I think so. Today I use "telnet" to get message from QOTD server, but
it does not handle any handshake. Just standard TCP connection.
I would suggest you to work with vpnc as is today and write the code
to talk with QOTD server "outside" vpnc. This gives you the
flexibility to run it more than once in the same connection. When you
get something working we could think about integrating it in vpnc or
keeping it as separate binary.

Best Regards,
Antonio Borneo


> Please help. I really want to use Linux at work, but at the moment I must
> use virtual Windows to connect to vpn.
>
> Regards
> Jakub
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/

Hi Antonio,

I got too deep into details, but wanted to share the level of my knowledge
on protocols/tcpip/networking on the start. Which is really basic.

I meant that on Windows (I scan a Nortel network device, not regular
network card for regular uses), I see communication with only one IP ( port
17 ;-) ), thus this IP sends the banner and when I click "Accept" the
traffic begins. So I assume a similar action must happen on Linux (or more
- despiite the OS).
On LInux, I connect with telnet to QOTD on port 17, get the message/banner
and connection closes automatically. So does VPN connection.

Can You tell in more details why to connect to QOTD server? How to send a
response to QOTD server? I assume this will make a stable connection with
VPN.

Regards
Jakub

2012/10/31 Antonio Borneo <borneo.antonio@gmail.com>

> Hi Jakub,
>
> On Wed, Oct 31, 2012 at 7:28 AM, Jakub Pietkun <jpietkun@gmail.com> wrote:
> > Hello,
> >
> > With the help of wirechark I have analyzed what's going during
> establishing
> > a vpn connection on Windows. I see a 3-way handshake and further, a PUSH
> > packet. And finally, when Accept button is pressed, it sends a packet
> with
> > flags FIN,ACK and determined SEQ and ACK values to QOTD server. All those
> > packets are exchanged with the IP of QOTD server.
>
> These are very interesting observations.
> So there is a handshake on QOTD server following press of "Accept" button.
>
> > I cannot observe the same on Linux. In fact, in wireshark I cannot see
> tun
> > interface and don't know how to make wireshark see it. In fact, I cannot
> see
> > tun interface with command "ifconfig". I can observe network traffic
> only on
> > eth0 interface.
>
> You will not find the same sequence in Linux, since current vpnc does
> not implement any connection with QOTD server.
>
> The tun interface is normally created dynamically by vpnc at start,
> and destroyed as soon as vpnc exit.
> You can bypass this by creating a persistent tun interface with
> command tunctl, e.g. "tunctl -n -t tun3", then start wireshark on it.
> You also need to specify the persistent tun interface to vpnc, using
> command line "--ifname tun3" or "Interface name tun3" in config file.
>
> > What I tried is to send this packet to QOTD server with hping3 but it
> didn't
> > help. Probably I have to simulate all the "handshake" sequence.
>
> I think so. Today I use "telnet" to get message from QOTD server, but
> it does not handle any handshake. Just standard TCP connection.
> I would suggest you to work with vpnc as is today and write the code
> to talk with QOTD server "outside" vpnc. This gives you the
> flexibility to run it more than once in the same connection. When you
> get something working we could think about integrating it in vpnc or
> keeping it as separate binary.
>
> Best Regards,
> Antonio Borneo
>
>
> > Please help. I really want to use Linux at work, but at the moment I must
> > use virtual Windows to connect to vpn.
> >
> > Regards
> > Jakub
>