Control Chanel question

Forum for all technical support and trouble shooting of the WinGate VPN.

Moderator: Qbik Staff

Control Chanel question

Postby jeff » Jun 15 06 4:47 am

Hello !!!

I've just found a tricky behavour with the Control Chanel :

[VPN JOINER] ---- router ---- (INTERNET) ---- router --- [VPN SERVER]

With Ethereal Network Analyzer on WAN side, I can watch the control procedure every 50s :

a TCP control Packet [PSH,ACK] ---- Server ==> Joiner
an ICMP ECHO request [TTL=6] ---- Joiner ==> Server
an ICMP ECHO reply ---- Server ==> Joiner
a TCP control Packet [ACK] ---- Joiner ==> Server

on some of our "joiners", the ICMP ECHO request / reply is OK (same provider).
But on some others, it seems that the TTL=6 of the ICMP ECHO request is not enough and no ICMP ECHO reply comes from server (==> TTL exceeded).

- Why does the ICMP packet have a TTL=6 value ?

- Is this ICMP reply is important and needed for the Control chanel ?

- TCP packets are forwarded to Wingate, but ICMP packets are not : when TTL=6 is OK, then the reply comes from the Server's router (if configured to answer to ICMP requests). is it a normal behavour ??

I wonder if on older versions of Wingate VPN, theses ICMP packets waren't encrypted over UDP Data Chanel to the remote VPN Server IP Address Then TTL=6 would be OK in every case.

Thanks a lot for your answer !!!

Sorry for my english !!!

Jeff
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am

Postby genie » Jun 15 06 11:18 am

That's one of the ways for the engine to discover the availability of the remote machines/joiners - it pings machines behind VPN server and since it is only one hop away from the joiner, TTL 6 is enough for it. If the echo request is sent to the joiner itself and the joiner's IP address is exported as a secured route we do not pump the ICMP packets through the data channel but simply send them to the machine as normal traffic.
genie
Qbik Staff
 
Posts: 1788
Joined: Sep 30 03 10:29 am

Postby jeff » Jun 15 06 12:07 pm

"it is only one hop away from the joiner"

AS far as these ICMP packets are not going thru the VPN, the Wingate server's Public IP is mostly more then 6 hopes away from the joiner.
And as the ICMP packets are going directly to the Internet, they are only reaching the Wingate server's router only. (wich most of time never answer to PING requests).

for me :
joiner is the Wingate VPN client (VPN to join... side)
server is the Wingate VPN server (VPN to host ... side)

With v2.1.3, my Ethereal captures of the "control sequence" on WAN side 'external interface' of a joiner looks like this for most of remote offices :
1 - a TCP control Packet [PSH,ACK] - - - : Server's Public IP (Wingate server TCP Control port) ==> Joiner's Local IP (Free joiner TCP port)
2 - an ICMP ECHO request [TTL=6] - - - - : Joiner's Local IP ==> Server's Public IP (data = ping.)
3 - an ICMP TTL EXCEEDED Packet - - - - : 'one internet node' IP ==> Joiner's local IP
4 - a TCP control Packet [ACK] - - - - : Joiner's local IP (free joiner TCP port) ==> Server's Public IP(Wingate Server TCP Control port)

with v2.1.1, the same catupe was
1 - a TCP control Packet [PSH,ACK] ---- : Server's Public IP (Wingate server TCP Control port) ==> Joiner's local IP (Free joiner TCP port)
2 - an UDP packet (crypted) ---- : Joiner's local IP (Wingate joiner UDP data port) ==> Server's Public IP (Wingate Server UDP data port) :::: This is an encrypted ICMP REQUEST
3 - an UDP packet (crypted) ---- :Server's Public IP (Wingate Server UDP data port) ==> Joiner local IP (Wingate joiner's UDP data port) ::::: This is an encrypted ICMP REPLY
4 - a TCP control Packet [ACK] ---- : Joiner local IP (Free joiner TCP port) ==> Server's PublicIP (Wingate server TCP Control port)
==> I think this might be a correct behavior

I'm wondering if this 2.1.3 behavior is normal, as 99% of these ICMP are getting an "TTL exceeded" message answer from an Internet Node.
Last edited by jeff on Jun 15 06 12:12 pm, edited 1 time in total.
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am

Postby genie » Jun 15 06 12:10 pm

Aye, this is normal behavior - Wingate just doing some hosekeeping with this ICMP traffic.
genie
Qbik Staff
 
Posts: 1788
Joined: Sep 30 03 10:29 am

Postby jeff » Jun 15 06 12:40 pm

Then I just don't understand any more the need of this ICMP ECHO REQUEST..... ,
.... as far as it never reaches the VPN server, but only it's router (and only if it is 6 hopes away max from the VPN client machine and able to reply to ping requests)

I'm just wondering if I'll keep v2.1.3 or just roll back to 2.1.1

Could you also explain us what's new on v2.1.3 / v2.1.1 (what was wrong with 2.1.2 ???). Unable to find on the web site ....
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am

Postby genie » Jun 15 06 12:48 pm

There is nothing to worry about this echo requests - Wingate simply sends out these requests to all the machines in VPN connection it knows about - and if the machine is a joiner with no external interface exported as a VPN route, it simply sends an ICMP packet to the default route.
genie
Qbik Staff
 
Posts: 1788
Joined: Sep 30 03 10:29 am

Postby jeff » Jun 15 06 10:07 pm

I just made several Lab tests today.
This behavior (ICMP instead of UCP during the control sequence) is depending of Wingate VPN's Server's Version

Client v2.1.1 and Server v2.1.1 >>>> UDP packets (encrypted Ping)
Client v2.1.3 and Server v2.1.1 >>>> UDP packets (encrypted Ping)
Client v2.1.1 and Server v2.1.3 >>>> Direct ICMP Packets
Client v2.1.3 and Server v2.1.3 >>>> Direct ICMP Packets

For sure the behavior is not the same. why ?

As I thought that the UDP exchange during the "control sequence" was a part of security (crypting / decrypting) on both side, i'm a little bit disapointed.

I thought :
1 - Server sends a TCP control packet to client (every 50s)
2 - Client Receiving this TCP Control frame => sends an encrypted ICMP REQUEST to server (.... waiting for a valid reply ...)
3 - Server sends a valid encrypted ICMP REPLY to client.
4 - Client says "this packet is OK" (decrypt OK ) so VPN is UP on client side
5 - If Packet is OK then Client sends a TCP ACK to server
6 - Server receive TCP ACK so VPN is UP on server side.

in fact, it seems that those ICMP paquets are not usefull to keep the VPN UP. (for sure, because without forwarding UDP port on Server's router, the VPN is still "UP" on both side)
1 - server sends a TCP control Packet to client (PSH ACK) every 50' - he
2 - client says "VPN is UP" and sends a "TCP ACK" to server
3 - server says "VPN is UP"

if client doesn't receive the TCP control PSH ACK packet from server within 2 min, then client says VPN is down (max client time to set VPN "Down" is 2min)
if Server doesn't receive the TCP control Ack from client within 2 min, then server says VPN is down. (max server time to set VPN down => 2min50s)

Then for sure, those ICMP request packets are not usefull ... (isn't it possible to disable them, as they generally never get any reply ???)

best regards.
Jeff
jeff
 
Posts: 37
Joined: Apr 22 04 8:57 am


Return to WinGate VPN

Who is online

Users browsing this forum: No registered users and 22 guests

cron