Mailing List Archive

Hi Jakub,

On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com> wrote:
> 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 ;-)

just to confirm what you write:
On Windows PC you have (at least) one network interface that
corresponds to a real network device (ethernet or WiFi). When you
start VPN, on this interface you can only see encrypted packet, so not
really useful.
Beside it, there is another interface that is where all the
un-encrypted communication happens. This is where you run wireshark
and where you see communication with only one IP and only on port 17.
Correct?

>
> ), thus this IP sends the banner and when I click "Accept" the traffic
> begins.

With wireshark you can save the sniffed data.
If you send us the saved file, it could help to understand what has
been added to the simple TCP connection to QOTD.
I think you can share that file, since should not provide any secret
information.
The file will contain only the IP of the QOTD server, so no security
issue (that IP is only accessible when the VPN is already connected).
But will contain the message in the banner (e.g. could include company
name). I let you judge if it is safe to sent it out.
If you prefer, you can consider sending it only privately to my email.

It is still not clear if the communication with QOTD server it the
trigger to confirm the VPN connection. Could still be that some other
information is sent encrypted and not visible in your wireshark log.
But this is all what we have now.

Would be useful to save a file in which you do not press the "accept"
button, to see how the QOTD server replies (if it replies).
Then a second file in which you get the banner, wait 10 seconds then
press "accept", then wait at least other 10 seconds before stop
wireshark activity.

Would be also useful a third file taken in Linux.
Use a persistent tun on which you sniff with wireshark.
The start vpnc connection and within 30 seconds telnet to the QOTD server.
Don't know if you can provide it too.

> 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.

I only have access to an old Nortel server.
On this server the QOTD server follows the "usual" behaviour of
"every" QOTD servers.
It accept connections on port 17, as soon as the connection is
established the server sends a text message and server suddenly close
the TCP connection.

For what I understand by our talking, in your case the connection is
not closed immediately, but is waiting for some kind of reply from the
VPN client.
The simpler way to verify it is to write a simple program that mimic
the VPN client.
So using VPNC to create the encrypted tunnel then, in a separate
shell, run the connection to QOTD which includes the reply.

Antonio

>
> 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
>
>
_______________________________________________
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/

Dear all,
was this followed up further? I have another use complaining about vpnc disconnections after about 30 seconds. He also needs to confirm a banner dialog when using the Windows Nortel client. Maybe somebody wants to follow up with him? He is willing to provide logs etc. for debugging...

Best regards,
Fabian


Am 04.11.2012 um 06:16 schrieb Antonio Borneo <borneo.antonio@gmail.com>:

> Hi Jakub,
>
> On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com> wrote:
>> 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 ;-)
>
> just to confirm what you write:
> On Windows PC you have (at least) one network interface that
> corresponds to a real network device (ethernet or WiFi). When you
> start VPN, on this interface you can only see encrypted packet, so not
> really useful.
> Beside it, there is another interface that is where all the
> un-encrypted communication happens. This is where you run wireshark
> and where you see communication with only one IP and only on port 17.
> Correct?
>
>>
>> ), thus this IP sends the banner and when I click "Accept" the traffic
>> begins.
>
> With wireshark you can save the sniffed data.
> If you send us the saved file, it could help to understand what has
> been added to the simple TCP connection to QOTD.
> I think you can share that file, since should not provide any secret
> information.
> The file will contain only the IP of the QOTD server, so no security
> issue (that IP is only accessible when the VPN is already connected).
> But will contain the message in the banner (e.g. could include company
> name). I let you judge if it is safe to sent it out.
> If you prefer, you can consider sending it only privately to my email.
>
> It is still not clear if the communication with QOTD server it the
> trigger to confirm the VPN connection. Could still be that some other
> information is sent encrypted and not visible in your wireshark log.
> But this is all what we have now.
>
> Would be useful to save a file in which you do not press the "accept"
> button, to see how the QOTD server replies (if it replies).
> Then a second file in which you get the banner, wait 10 seconds then
> press "accept", then wait at least other 10 seconds before stop
> wireshark activity.
>
> Would be also useful a third file taken in Linux.
> Use a persistent tun on which you sniff with wireshark.
> The start vpnc connection and within 30 seconds telnet to the QOTD server.
> Don't know if you can provide it too.
>
>> 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.
>
> I only have access to an old Nortel server.
> On this server the QOTD server follows the "usual" behaviour of
> "every" QOTD servers.
> It accept connections on port 17, as soon as the connection is
> established the server sends a text message and server suddenly close
> the TCP connection.
>
> For what I understand by our talking, in your case the connection is
> not closed immediately, but is waiting for some kind of reply from the
> VPN client.
> The simpler way to verify it is to write a simple program that mimic
> the VPN client.
> So using VPNC to create the encrypted tunnel then, in a separate
> shell, run the connection to QOTD which includes the reply.
>
> Antonio
>
>>
>> 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
>>
>>
> _______________________________________________
> 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,

with Jakub we have identified that Avaya client sends a ISAKMP packet to
server when user press "accept" button.
So the trick is not in the QOTD server; it just carries the message
displayed with the button.

Unfortunately no idea how to replicate the behavior in vpnc.
We need to decrypt and analyze the ISAKMP packet.
I do not have anymore a valid account to use for this purpose.

Best Regards,
Antonio


On Wed, Jun 19, 2013 at 9:38 PM, "[ChungwaSoft] Fabian Jäger" <
fabian.jaeger@chungwasoft.com> wrote:

> Dear all,
> was this followed up further? I have another use complaining about vpnc
> disconnections after about 30 seconds. He also needs to confirm a banner
> dialog when using the Windows Nortel client. Maybe somebody wants to follow
> up with him? He is willing to provide logs etc. for debugging...
>
> Best regards,
> Fabian
>
>
> Am 04.11.2012 um 06:16 schrieb Antonio Borneo <borneo.antonio@gmail.com>:
>
> > Hi Jakub,
> >
> > On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com>
> wrote:
> >> 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
> ;-)
> >
> > just to confirm what you write:
> > On Windows PC you have (at least) one network interface that
> > corresponds to a real network device (ethernet or WiFi). When you
> > start VPN, on this interface you can only see encrypted packet, so not
> > really useful.
> > Beside it, there is another interface that is where all the
> > un-encrypted communication happens. This is where you run wireshark
> > and where you see communication with only one IP and only on port 17.
> > Correct?
> >
> >>
> >> ), thus this IP sends the banner and when I click "Accept" the traffic
> >> begins.
> >
> > With wireshark you can save the sniffed data.
> > If you send us the saved file, it could help to understand what has
> > been added to the simple TCP connection to QOTD.
> > I think you can share that file, since should not provide any secret
> > information.
> > The file will contain only the IP of the QOTD server, so no security
> > issue (that IP is only accessible when the VPN is already connected).
> > But will contain the message in the banner (e.g. could include company
> > name). I let you judge if it is safe to sent it out.
> > If you prefer, you can consider sending it only privately to my email.
> >
> > It is still not clear if the communication with QOTD server it the
> > trigger to confirm the VPN connection. Could still be that some other
> > information is sent encrypted and not visible in your wireshark log.
> > But this is all what we have now.
> >
> > Would be useful to save a file in which you do not press the "accept"
> > button, to see how the QOTD server replies (if it replies).
> > Then a second file in which you get the banner, wait 10 seconds then
> > press "accept", then wait at least other 10 seconds before stop
> > wireshark activity.
> >
> > Would be also useful a third file taken in Linux.
> > Use a persistent tun on which you sniff with wireshark.
> > The start vpnc connection and within 30 seconds telnet to the QOTD
> server.
> > Don't know if you can provide it too.
> >
> >> 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.
> >
> > I only have access to an old Nortel server.
> > On this server the QOTD server follows the "usual" behaviour of
> > "every" QOTD servers.
> > It accept connections on port 17, as soon as the connection is
> > established the server sends a text message and server suddenly close
> > the TCP connection.
> >
> > For what I understand by our talking, in your case the connection is
> > not closed immediately, but is waiting for some kind of reply from the
> > VPN client.
> > The simpler way to verify it is to write a simple program that mimic
> > the VPN client.
> > So using VPNC to create the encrypted tunnel then, in a separate
> > shell, run the connection to QOTD which includes the reply.
> >
> > Antonio
> >
> >>
> >> 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
> >>
> >>
> > _______________________________________________
> > 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 am also running into this issue. I have wireshark installed on a Windows
client (virtual machine actually) that can successfully connect through the
banner message, but have been unable to decode the ISAKMP packets.

How do I determine whether IKEv1 or IKEv2 is being used? The ISAKMP packets
containing the security proposals mentions IKE, but I cannot tell which
version. Once I know the correct version, I can then try to find the
necessary inputs to the ISAKMP decryption tables.

I did take stab at filling out the ISAKMP decryption tables without
success. I first tried the IKEv1 table and used the initiator cookie and
key exchange data from the initial ISAKMP packet from the client. I then
tried the IKEv2 table, but was unable to determine which protocol was being
used and where I could find all of the required keys (made some guesses
using the cookies, and the key exchange data but unsuccessful due to the
keys being too large for the encryption algorithms I tried). Any help on
what to try is appreciated.


-Jim



On Wed, Jun 19, 2013 at 11:20 AM, Antonio Borneo
<borneo.antonio@gmail.com>wrote:

> Hi Fabian,
>
> with Jakub we have identified that Avaya client sends a ISAKMP packet to
> server when user press "accept" button.
> So the trick is not in the QOTD server; it just carries the message
> displayed with the button.
>
> Unfortunately no idea how to replicate the behavior in vpnc.
> We need to decrypt and analyze the ISAKMP packet.
> I do not have anymore a valid account to use for this purpose.
>
> Best Regards,
> Antonio
>
>
> On Wed, Jun 19, 2013 at 9:38 PM, "[ChungwaSoft] Fabian Jäger" <
> fabian.jaeger@chungwasoft.com> wrote:
>
>> Dear all,
>> was this followed up further? I have another use complaining about vpnc
>> disconnections after about 30 seconds. He also needs to confirm a banner
>> dialog when using the Windows Nortel client. Maybe somebody wants to follow
>> up with him? He is willing to provide logs etc. for debugging...
>>
>> Best regards,
>> Fabian
>>
>>
>> Am 04.11.2012 um 06:16 schrieb Antonio Borneo <borneo.antonio@gmail.com>:
>>
>> > Hi Jakub,
>> >
>> > On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com>
>> wrote:
>> >> 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
>> ;-)
>> >
>> > just to confirm what you write:
>> > On Windows PC you have (at least) one network interface that
>> > corresponds to a real network device (ethernet or WiFi). When you
>> > start VPN, on this interface you can only see encrypted packet, so not
>> > really useful.
>> > Beside it, there is another interface that is where all the
>> > un-encrypted communication happens. This is where you run wireshark
>> > and where you see communication with only one IP and only on port 17.
>> > Correct?
>> >
>> >>
>> >> ), thus this IP sends the banner and when I click "Accept" the traffic
>> >> begins.
>> >
>> > With wireshark you can save the sniffed data.
>> > If you send us the saved file, it could help to understand what has
>> > been added to the simple TCP connection to QOTD.
>> > I think you can share that file, since should not provide any secret
>> > information.
>> > The file will contain only the IP of the QOTD server, so no security
>> > issue (that IP is only accessible when the VPN is already connected).
>> > But will contain the message in the banner (e.g. could include company
>> > name). I let you judge if it is safe to sent it out.
>> > If you prefer, you can consider sending it only privately to my email.
>> >
>> > It is still not clear if the communication with QOTD server it the
>> > trigger to confirm the VPN connection. Could still be that some other
>> > information is sent encrypted and not visible in your wireshark log.
>> > But this is all what we have now.
>> >
>> > Would be useful to save a file in which you do not press the "accept"
>> > button, to see how the QOTD server replies (if it replies).
>> > Then a second file in which you get the banner, wait 10 seconds then
>> > press "accept", then wait at least other 10 seconds before stop
>> > wireshark activity.
>> >
>> > Would be also useful a third file taken in Linux.
>> > Use a persistent tun on which you sniff with wireshark.
>> > The start vpnc connection and within 30 seconds telnet to the QOTD
>> server.
>> > Don't know if you can provide it too.
>> >
>> >> 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.
>> >
>> > I only have access to an old Nortel server.
>> > On this server the QOTD server follows the "usual" behaviour of
>> > "every" QOTD servers.
>> > It accept connections on port 17, as soon as the connection is
>> > established the server sends a text message and server suddenly close
>> > the TCP connection.
>> >
>> > For what I understand by our talking, in your case the connection is
>> > not closed immediately, but is waiting for some kind of reply from the
>> > VPN client.
>> > The simpler way to verify it is to write a simple program that mimic
>> > the VPN client.
>> > So using VPNC to create the encrypted tunnel then, in a separate
>> > shell, run the connection to QOTD which includes the reply.
>> >
>> > Antonio
>> >
>> >>
>> >> 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
>> >>
>> >>
>> > _______________________________________________
>> > 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/
>
>

To me it sounds we are not that far from a solution...

Would be really awesome if we could find out how this banner answer packet looks like and emulate the functionality with vpnc!

Fabian

Am 19.06.2013 um 20:58 schrieb Jim Shepherd <jeshep@gmail.com>:

> I am also running into this issue. I have wireshark installed on a Windows client (virtual machine actually) that can successfully connect through the banner message, but have been unable to decode the ISAKMP packets.
>
> How do I determine whether IKEv1 or IKEv2 is being used? The ISAKMP packets containing the security proposals mentions IKE, but I cannot tell which version. Once I know the correct version, I can then try to find the necessary inputs to the ISAKMP decryption tables.
>
> I did take stab at filling out the ISAKMP decryption tables without success. I first tried the IKEv1 table and used the initiator cookie and key exchange data from the initial ISAKMP packet from the client. I then tried the IKEv2 table, but was unable to determine which protocol was being used and where I could find all of the required keys (made some guesses using the cookies, and the key exchange data but unsuccessful due to the keys being too large for the encryption algorithms I tried). Any help on what to try is appreciated.
>
>
> -Jim
>
>
>
> On Wed, Jun 19, 2013 at 11:20 AM, Antonio Borneo <borneo.antonio@gmail.com> wrote:
> Hi Fabian,
>
> with Jakub we have identified that Avaya client sends a ISAKMP packet to server when user press "accept" button.
> So the trick is not in the QOTD server; it just carries the message displayed with the button.
>
> Unfortunately no idea how to replicate the behavior in vpnc.
> We need to decrypt and analyze the ISAKMP packet.
> I do not have anymore a valid account to use for this purpose.
>
> Best Regards,
> Antonio
>
>
> On Wed, Jun 19, 2013 at 9:38 PM, "[ChungwaSoft] Fabian Jäger" <fabian.jaeger@chungwasoft.com> wrote:
> Dear all,
> was this followed up further? I have another use complaining about vpnc disconnections after about 30 seconds. He also needs to confirm a banner dialog when using the Windows Nortel client. Maybe somebody wants to follow up with him? He is willing to provide logs etc. for debugging...
>
> Best regards,
> Fabian
>
>
> Am 04.11.2012 um 06:16 schrieb Antonio Borneo <borneo.antonio@gmail.com>:
>
> > Hi Jakub,
> >
> > On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com> wrote:
> >> 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 ;-)
> >
> > just to confirm what you write:
> > On Windows PC you have (at least) one network interface that
> > corresponds to a real network device (ethernet or WiFi). When you
> > start VPN, on this interface you can only see encrypted packet, so not
> > really useful.
> > Beside it, there is another interface that is where all the
> > un-encrypted communication happens. This is where you run wireshark
> > and where you see communication with only one IP and only on port 17.
> > Correct?
> >
> >>
> >> ), thus this IP sends the banner and when I click "Accept" the traffic
> >> begins.
> >
> > With wireshark you can save the sniffed data.
> > If you send us the saved file, it could help to understand what has
> > been added to the simple TCP connection to QOTD.
> > I think you can share that file, since should not provide any secret
> > information.
> > The file will contain only the IP of the QOTD server, so no security
> > issue (that IP is only accessible when the VPN is already connected).
> > But will contain the message in the banner (e.g. could include company
> > name). I let you judge if it is safe to sent it out.
> > If you prefer, you can consider sending it only privately to my email.
> >
> > It is still not clear if the communication with QOTD server it the
> > trigger to confirm the VPN connection. Could still be that some other
> > information is sent encrypted and not visible in your wireshark log.
> > But this is all what we have now.
> >
> > Would be useful to save a file in which you do not press the "accept"
> > button, to see how the QOTD server replies (if it replies).
> > Then a second file in which you get the banner, wait 10 seconds then
> > press "accept", then wait at least other 10 seconds before stop
> > wireshark activity.
> >
> > Would be also useful a third file taken in Linux.
> > Use a persistent tun on which you sniff with wireshark.
> > The start vpnc connection and within 30 seconds telnet to the QOTD server.
> > Don't know if you can provide it too.
> >
> >> 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.
> >
> > I only have access to an old Nortel server.
> > On this server the QOTD server follows the "usual" behaviour of
> > "every" QOTD servers.
> > It accept connections on port 17, as soon as the connection is
> > established the server sends a text message and server suddenly close
> > the TCP connection.
> >
> > For what I understand by our talking, in your case the connection is
> > not closed immediately, but is waiting for some kind of reply from the
> > VPN client.
> > The simpler way to verify it is to write a simple program that mimic
> > the VPN client.
> > So using VPNC to create the encrypted tunnel then, in a separate
> > shell, run the connection to QOTD which includes the reply.
> >
> > Antonio
> >
> >>
> >> 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
> >>
> >>
> > _______________________________________________
> > 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/
>
>

Hello!

I haven't found time to do anything with the subject.
I only have this page with decryption of IKEv1:
http://ask.wireshark.org/questions/12019/how-can-i-decrypt-ikev1-packets
...which probably all of You already know.
Though, I am still interested in resolving this issue and will get back to
the thread with anything significant. Recently my colleague have used vpnc
too, but he faces the same issue.

Kind Regards
Jakub


2013/6/21 Fabian Jäger <fabian.jaeger@chungwasoft.com>

> To me it sounds we are not that far from a solution...
>
> Would be really awesome if we could find out how this banner answer packet
> looks like and emulate the functionality with vpnc!
>
> Fabian
>
> Am 19.06.2013 um 20:58 schrieb Jim Shepherd <jeshep@gmail.com>:
>
> I am also running into this issue. I have wireshark installed on a Windows
> client (virtual machine actually) that can successfully connect through the
> banner message, but have been unable to decode the ISAKMP packets.
>
> How do I determine whether IKEv1 or IKEv2 is being used? The ISAKMP
> packets containing the security proposals mentions IKE, but I cannot tell
> which version. Once I know the correct version, I can then try to find the
> necessary inputs to the ISAKMP decryption tables.
>
> I did take stab at filling out the ISAKMP decryption tables without
> success. I first tried the IKEv1 table and used the initiator cookie and
> key exchange data from the initial ISAKMP packet from the client. I then
> tried the IKEv2 table, but was unable to determine which protocol was being
> used and where I could find all of the required keys (made some guesses
> using the cookies, and the key exchange data but unsuccessful due to the
> keys being too large for the encryption algorithms I tried). Any help on
> what to try is appreciated.
>
>
> -Jim
>
>
>
> On Wed, Jun 19, 2013 at 11:20 AM, Antonio Borneo <borneo.antonio@gmail.com
> > wrote:
>
>> Hi Fabian,
>>
>> with Jakub we have identified that Avaya client sends a ISAKMP packet to
>> server when user press "accept" button.
>> So the trick is not in the QOTD server; it just carries the message
>> displayed with the button.
>>
>> Unfortunately no idea how to replicate the behavior in vpnc.
>> We need to decrypt and analyze the ISAKMP packet.
>> I do not have anymore a valid account to use for this purpose.
>>
>> Best Regards,
>> Antonio
>>
>>
>> On Wed, Jun 19, 2013 at 9:38 PM, "[ChungwaSoft] Fabian Jäger" <
>> fabian.jaeger@chungwasoft.com> wrote:
>>
>>> Dear all,
>>> was this followed up further? I have another use complaining about vpnc
>>> disconnections after about 30 seconds. He also needs to confirm a banner
>>> dialog when using the Windows Nortel client. Maybe somebody wants to follow
>>> up with him? He is willing to provide logs etc. for debugging...
>>>
>>> Best regards,
>>> Fabian
>>>
>>>
>>> Am 04.11.2012 um 06:16 schrieb Antonio Borneo <borneo.antonio@gmail.com
>>> >:
>>>
>>> > Hi Jakub,
>>> >
>>> > On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com>
>>> wrote:
>>> >> 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 ;-)
>>> >
>>> > just to confirm what you write:
>>> > On Windows PC you have (at least) one network interface that
>>> > corresponds to a real network device (ethernet or WiFi). When you
>>> > start VPN, on this interface you can only see encrypted packet, so not
>>> > really useful.
>>> > Beside it, there is another interface that is where all the
>>> > un-encrypted communication happens. This is where you run wireshark
>>> > and where you see communication with only one IP and only on port 17.
>>> > Correct?
>>> >
>>> >>
>>> >> ), thus this IP sends the banner and when I click "Accept" the traffic
>>> >> begins.
>>> >
>>> > With wireshark you can save the sniffed data.
>>> > If you send us the saved file, it could help to understand what has
>>> > been added to the simple TCP connection to QOTD.
>>> > I think you can share that file, since should not provide any secret
>>> > information.
>>> > The file will contain only the IP of the QOTD server, so no security
>>> > issue (that IP is only accessible when the VPN is already connected).
>>> > But will contain the message in the banner (e.g. could include company
>>> > name). I let you judge if it is safe to sent it out.
>>> > If you prefer, you can consider sending it only privately to my email.
>>> >
>>> > It is still not clear if the communication with QOTD server it the
>>> > trigger to confirm the VPN connection. Could still be that some other
>>> > information is sent encrypted and not visible in your wireshark log.
>>> > But this is all what we have now.
>>> >
>>> > Would be useful to save a file in which you do not press the "accept"
>>> > button, to see how the QOTD server replies (if it replies).
>>> > Then a second file in which you get the banner, wait 10 seconds then
>>> > press "accept", then wait at least other 10 seconds before stop
>>> > wireshark activity.
>>> >
>>> > Would be also useful a third file taken in Linux.
>>> > Use a persistent tun on which you sniff with wireshark.
>>> > The start vpnc connection and within 30 seconds telnet to the QOTD
>>> server.
>>> > Don't know if you can provide it too.
>>> >
>>> >> 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.
>>> >
>>> > I only have access to an old Nortel server.
>>> > On this server the QOTD server follows the "usual" behaviour of
>>> > "every" QOTD servers.
>>> > It accept connections on port 17, as soon as the connection is
>>> > established the server sends a text message and server suddenly close
>>> > the TCP connection.
>>> >
>>> > For what I understand by our talking, in your case the connection is
>>> > not closed immediately, but is waiting for some kind of reply from the
>>> > VPN client.
>>> > The simpler way to verify it is to write a simple program that mimic
>>> > the VPN client.
>>> > So using VPNC to create the encrypted tunnel then, in a separate
>>> > shell, run the connection to QOTD which includes the reply.
>>> >
>>> > Antonio
>>> >
>>> >>
>>> >> 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
>>> >>
>>> >>
>>> > _______________________________________________
>>> > 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/
>>
>>
>
>
> _______________________________________________
> 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 have the time and motivation to help get this issue resolved, I just
don't have the knowledge to decrypt the ISAKMP and ESP packets that likely
contain the relevant issue to understand the communications related to the
banner acceptance.

My set up is a Fedora Linux laptop with vpnc and wireshark (an any other
tools necessary) and a Windows 7 VirtualBox vm running the Avaya VPN Client
10.06.104 and wireshark. I can install additional tools on my laptop, but I
do not have access to the VPN server and do not expect anyone in our IT
department to provide assistance (large company).

I have tried to decrypt the packets captured during a successful VPN
connection with wireshark on the Windows 7 vm, but have not been successful
with either the ISAKMP or ESP packets. Of course the stumbling block is
getting the correct IKE keys. I have spend a few hours reading various
sites including the one linked by Jakub, but it seems that the available
tools only run on Linux or a Windows VPN server. However, it also seems
that it is possible to get the keys from the client side since vpnc seems
to provide at least some of them. Any help on how to determine the keys or
extract them from the initial ISAKMP packets is appreciated.

-Jim


On Fri, Jun 21, 2013 at 3:37 PM, Jakub Pietkun <jpietkun@gmail.com> wrote:

> Hello!
>
> I haven't found time to do anything with the subject.
> I only have this page with decryption of IKEv1:
> http://ask.wireshark.org/questions/12019/how-can-i-decrypt-ikev1-packets
> ...which probably all of You already know.
> Though, I am still interested in resolving this issue and will get back to
> the thread with anything significant. Recently my colleague have used vpnc
> too, but he faces the same issue.
>
> Kind Regards
> Jakub
>
>
> 2013/6/21 Fabian Jäger <fabian.jaeger@chungwasoft.com>
>
>> To me it sounds we are not that far from a solution...
>>
>> Would be really awesome if we could find out how this banner answer
>> packet looks like and emulate the functionality with vpnc!
>>
>> Fabian
>>
>> Am 19.06.2013 um 20:58 schrieb Jim Shepherd <jeshep@gmail.com>:
>>
>> I am also running into this issue. I have wireshark installed on a
>> Windows client (virtual machine actually) that can successfully connect
>> through the banner message, but have been unable to decode the ISAKMP
>> packets.
>>
>> How do I determine whether IKEv1 or IKEv2 is being used? The ISAKMP
>> packets containing the security proposals mentions IKE, but I cannot tell
>> which version. Once I know the correct version, I can then try to find the
>> necessary inputs to the ISAKMP decryption tables.
>>
>> I did take stab at filling out the ISAKMP decryption tables without
>> success. I first tried the IKEv1 table and used the initiator cookie and
>> key exchange data from the initial ISAKMP packet from the client. I then
>> tried the IKEv2 table, but was unable to determine which protocol was being
>> used and where I could find all of the required keys (made some guesses
>> using the cookies, and the key exchange data but unsuccessful due to the
>> keys being too large for the encryption algorithms I tried). Any help on
>> what to try is appreciated.
>>
>>
>> -Jim
>>
>>
>>
>> On Wed, Jun 19, 2013 at 11:20 AM, Antonio Borneo <
>> borneo.antonio@gmail.com> wrote:
>>
>>> Hi Fabian,
>>>
>>> with Jakub we have identified that Avaya client sends a ISAKMP packet to
>>> server when user press "accept" button.
>>> So the trick is not in the QOTD server; it just carries the message
>>> displayed with the button.
>>>
>>> Unfortunately no idea how to replicate the behavior in vpnc.
>>> We need to decrypt and analyze the ISAKMP packet.
>>> I do not have anymore a valid account to use for this purpose.
>>>
>>> Best Regards,
>>> Antonio
>>>
>>>
>>> On Wed, Jun 19, 2013 at 9:38 PM, "[ChungwaSoft] Fabian Jäger" <
>>> fabian.jaeger@chungwasoft.com> wrote:
>>>
>>>> Dear all,
>>>> was this followed up further? I have another use complaining about vpnc
>>>> disconnections after about 30 seconds. He also needs to confirm a banner
>>>> dialog when using the Windows Nortel client. Maybe somebody wants to follow
>>>> up with him? He is willing to provide logs etc. for debugging...
>>>>
>>>> Best regards,
>>>> Fabian
>>>>
>>>>
>>>> Am 04.11.2012 um 06:16 schrieb Antonio Borneo <borneo.antonio@gmail.com
>>>> >:
>>>>
>>>> > Hi Jakub,
>>>> >
>>>> > On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com>
>>>> wrote:
>>>> >> 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 ;-)
>>>> >
>>>> > just to confirm what you write:
>>>> > On Windows PC you have (at least) one network interface that
>>>> > corresponds to a real network device (ethernet or WiFi). When you
>>>> > start VPN, on this interface you can only see encrypted packet, so not
>>>> > really useful.
>>>> > Beside it, there is another interface that is where all the
>>>> > un-encrypted communication happens. This is where you run wireshark
>>>> > and where you see communication with only one IP and only on port 17.
>>>> > Correct?
>>>> >
>>>> >>
>>>> >> ), thus this IP sends the banner and when I click "Accept" the
>>>> traffic
>>>> >> begins.
>>>> >
>>>> > With wireshark you can save the sniffed data.
>>>> > If you send us the saved file, it could help to understand what has
>>>> > been added to the simple TCP connection to QOTD.
>>>> > I think you can share that file, since should not provide any secret
>>>> > information.
>>>> > The file will contain only the IP of the QOTD server, so no security
>>>> > issue (that IP is only accessible when the VPN is already connected).
>>>> > But will contain the message in the banner (e.g. could include company
>>>> > name). I let you judge if it is safe to sent it out.
>>>> > If you prefer, you can consider sending it only privately to my email.
>>>> >
>>>> > It is still not clear if the communication with QOTD server it the
>>>> > trigger to confirm the VPN connection. Could still be that some other
>>>> > information is sent encrypted and not visible in your wireshark log.
>>>> > But this is all what we have now.
>>>> >
>>>> > Would be useful to save a file in which you do not press the "accept"
>>>> > button, to see how the QOTD server replies (if it replies).
>>>> > Then a second file in which you get the banner, wait 10 seconds then
>>>> > press "accept", then wait at least other 10 seconds before stop
>>>> > wireshark activity.
>>>> >
>>>> > Would be also useful a third file taken in Linux.
>>>> > Use a persistent tun on which you sniff with wireshark.
>>>> > The start vpnc connection and within 30 seconds telnet to the QOTD
>>>> server.
>>>> > Don't know if you can provide it too.
>>>> >
>>>> >> 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.
>>>> >
>>>> > I only have access to an old Nortel server.
>>>> > On this server the QOTD server follows the "usual" behaviour of
>>>> > "every" QOTD servers.
>>>> > It accept connections on port 17, as soon as the connection is
>>>> > established the server sends a text message and server suddenly close
>>>> > the TCP connection.
>>>> >
>>>> > For what I understand by our talking, in your case the connection is
>>>> > not closed immediately, but is waiting for some kind of reply from the
>>>> > VPN client.
>>>> > The simpler way to verify it is to write a simple program that mimic
>>>> > the VPN client.
>>>> > So using VPNC to create the encrypted tunnel then, in a separate
>>>> > shell, run the connection to QOTD which includes the reply.
>>>> >
>>>> > Antonio
>>>> >
>>>> >>
>>>> >> 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
>>>> >>
>>>> >>
>>>> > _______________________________________________
>>>> > 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/
>>>
>>>
>>
>>
>> _______________________________________________
>> 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/
>>
>>
>

Dear Antonio, all,
is there any progress on this "accept issue" with Nortel connections? If it helps, I could provide a Nortel box for debugging...

Best regards,
Fabian


Am 19.06.2013 um 17:20 schrieb Antonio Borneo <borneo.antonio@gmail.com>:

> Hi Fabian,
>
> with Jakub we have identified that Avaya client sends a ISAKMP packet to server when user press "accept" button.
> So the trick is not in the QOTD server; it just carries the message displayed with the button.
>
> Unfortunately no idea how to replicate the behavior in vpnc.
> We need to decrypt and analyze the ISAKMP packet.
> I do not have anymore a valid account to use for this purpose.
>
> Best Regards,
> Antonio
>
>
> On Wed, Jun 19, 2013 at 9:38 PM, "[ChungwaSoft] Fabian Jäger" <fabian.jaeger@chungwasoft.com> wrote:
> Dear all,
> was this followed up further? I have another use complaining about vpnc disconnections after about 30 seconds. He also needs to confirm a banner dialog when using the Windows Nortel client. Maybe somebody wants to follow up with him? He is willing to provide logs etc. for debugging...
>
> Best regards,
> Fabian
>
>
> Am 04.11.2012 um 06:16 schrieb Antonio Borneo <borneo.antonio@gmail.com>:
>
> > Hi Jakub,
> >
> > On Fri, Nov 2, 2012 at 3:40 PM, Jakub Pietkun <jpietkun@gmail.com> wrote:
> >> 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 ;-)
> >
> > just to confirm what you write:
> > On Windows PC you have (at least) one network interface that
> > corresponds to a real network device (ethernet or WiFi). When you
> > start VPN, on this interface you can only see encrypted packet, so not
> > really useful.
> > Beside it, there is another interface that is where all the
> > un-encrypted communication happens. This is where you run wireshark
> > and where you see communication with only one IP and only on port 17.
> > Correct?
> >
> >>
> >> ), thus this IP sends the banner and when I click "Accept" the traffic
> >> begins.
> >
> > With wireshark you can save the sniffed data.
> > If you send us the saved file, it could help to understand what has
> > been added to the simple TCP connection to QOTD.
> > I think you can share that file, since should not provide any secret
> > information.
> > The file will contain only the IP of the QOTD server, so no security
> > issue (that IP is only accessible when the VPN is already connected).
> > But will contain the message in the banner (e.g. could include company
> > name). I let you judge if it is safe to sent it out.
> > If you prefer, you can consider sending it only privately to my email.
> >
> > It is still not clear if the communication with QOTD server it the
> > trigger to confirm the VPN connection. Could still be that some other
> > information is sent encrypted and not visible in your wireshark log.
> > But this is all what we have now.
> >
> > Would be useful to save a file in which you do not press the "accept"
> > button, to see how the QOTD server replies (if it replies).
> > Then a second file in which you get the banner, wait 10 seconds then
> > press "accept", then wait at least other 10 seconds before stop
> > wireshark activity.
> >
> > Would be also useful a third file taken in Linux.
> > Use a persistent tun on which you sniff with wireshark.
> > The start vpnc connection and within 30 seconds telnet to the QOTD server.
> > Don't know if you can provide it too.
> >
> >> 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.
> >
> > I only have access to an old Nortel server.
> > On this server the QOTD server follows the "usual" behaviour of
> > "every" QOTD servers.
> > It accept connections on port 17, as soon as the connection is
> > established the server sends a text message and server suddenly close
> > the TCP connection.
> >
> > For what I understand by our talking, in your case the connection is
> > not closed immediately, but is waiting for some kind of reply from the
> > VPN client.
> > The simpler way to verify it is to write a simple program that mimic
> > the VPN client.
> > So using VPNC to create the encrypted tunnel then, in a separate
> > shell, run the connection to QOTD which includes the reply.
> >
> > Antonio
> >
> >>
> >> 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
> >>
> >>
> > _______________________________________________
> > 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/
>
>