How to tinc windows 2k client to linux server

  • Thread starter Thread starter Christian Maier
  • Start date Start date
C

Christian Maier

Hello!

I am running a Debiag Sarge server (2.4.27 Kernel) and want to connect
a Windows 2K Client over the internet via VPN. I thought that a tinc
VPN
is the best way with my linux kernel (cause there are no patches
required). I set up all like this:

1. Serverside:

/etc/tinc/vpn/tinc.conf:
Name = ciserver
Device = /dev/net/tun

/etc/tinc/vpn/hosts/server:
Compression=9
Address vpn.mydomain.de
Subnet = 10.1.1.1
----BEGIN RSA PUBLIC KEY-----
somersakeydata
----END RSA PUBLIC KEY-----

/etc/tinc/vpn/hosts/home:
Compression=9
Adress=officeroutersIP
Subnet = 10.1.1.2
----BEGIN RSA PUBLIC KEY-----
someotherrsakeydata
----END RSA PUBLIC KEY-----

Datei /etc/tinc/vpn/tinc-up:
#!/bin/bash
ifconfig vpn 10.1.1.1 netmask 255.255.255.0 broadcast 10.1.1.255
-arp

And of course there are the tinc Keyfiles generated too.

2. Client Sinde (Win2K):
Installed Tinc, openssl, tap32, lbz, zlib

Then made the folders like serverside and copied the host files to
client via scp
In windows there are no tinc-up file cause this is defined in the
networking interface.
so I set
ip=10.1.1.2
mask=255.255.2550
gateway=myhomeroutersIP
DNS1 myhomeroutersIP
DNS2 none

And here ist the Problem:
When I ping with my windoze trough the VPN a serversided tail
/var/log/syslog sais:

Jan 3 11:24:30 localhost tinc.consult-it[27717]: Node home
(80.108.85.21 port 655) became reachable
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Got REQ_KEY from home
(80.108.85.21 port 6343): 15 home ciserver
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Sending ANS_KEY to
home (80.108.85.21 port 6343): 16 ciserver home
09005989A8CBF63ABE510FC6A3F1EB515EAF1700629C8E8E 91 64 4 9
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Sending 76 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Received UDP packet
from unknown source 80.108.85.21 port 6655
Jan 3 11:25:40 localhost tinc.consult-it[27717]: Received UDP packet
from unknown source 80.108.85.21 port 6655
Jan 3 11:25:45 localhost tinc.consult-it[27717]: Received UDP packet
from unknown source 80.108.85.21 port 6655
Jan 3 11:26:01 localhost tinc.consult-it[27717]: Sending PING to home
(80.108.85.21 port 6343): 8
Jan 3 11:26:01 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:26:01 localhost tinc.consult-it[27717]: Got PONG from home
(80.108.85.21 port 6343): 9
Jan 3 11:27:34 localhost tinc.consult-it[27717]: Got PING from home
(80.108.85.21 port 6343): 8
Jan 3 11:27:34 localhost tinc.consult-it[27717]: Sending PONG to home
(80.108.85.21 port 6343): 9
Jan 3 11:27:34 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:28:03 localhost tinc.consult-it[27717]: Regenerating
symmetric key
Jan 3 11:28:03 localhost tinc.consult-it[27717]: Sending KEY_CHANGED
to everyone (BROADCAST): 14 364d5d0 ciserver
Jan 3 11:28:03 localhost tinc.consult-it[27717]: Sending 20 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:29:04 localhost tinc.consult-it[27717]: Sending PING to home
(80.108.85.21 port 6343): 8
Jan 3 11:29:04 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:29:04 localhost tinc.consult-it[27717]: Got PONG from home
(80.108.85.21 port 6343): 9
Jan 3 11:30:37 localhost tinc.consult-it[27717]: Got PING from home
(80.108.85.21 port 6343): 8
Jan 3 11:30:37 localhost tinc.consult-it[27717]: Sending PONG to home
(80.108.85.21 port 6343): 9
Jan 3 11:30:37 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:32:07 localhost tinc.consult-it[27717]: Sending PING to home
(80.108.85.21 port 6343): 8
Jan 3 11:32:07 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:32:07 localhost tinc.consult-it[27717]: Got PONG from home
(80.108.85.21 port 6343): 9

OK, in fact: I am 80.108.85.21
But the Ping Packages never arrive my windoze client. The equivalent
happens if I ping from server to client.

Where got the packages lost??

Note: there are no firewallrules active while thesting the connection
(either client nor server sided)!

Thank you!!

Christain Maier
 
Christian Maier said:
Hello!

I am running a Debiag Sarge server (2.4.27 Kernel) and want to connect
a Windows 2K Client over the internet via VPN. I thought that a tinc
VPN
is the best way with my linux kernel (cause there are no patches
required). I set up all like this:

1. Serverside:

/etc/tinc/vpn/tinc.conf:
Name = ciserver
Device = /dev/net/tun
And of course there are the tinc Keyfiles generated too.

2. Client Sinde (Win2K):
Installed Tinc, openssl, tap32, lbz, zlib
<snip>

You will likely get more help with Linux VPNs and their
logs by asking a Linux focused list.

And here ist the Problem:
When I ping with my windoze trough the VPN a serversided tail

But you also need to try to be more careful with your
spelling and wording, as well as very specific about
your actual problem.

(I don't criticize spelling as mine is very poor online, but
it has to be good enough we know what words you are using
or meaning.)
Jan 3 11:32:07 localhost tinc.consult-it[27717]: Got PONG from home
(80.108.85.21 port 6343): 9

OK, in fact: I am 80.108.85.21
But the Ping Packages never arrive my windoze client. The equivalent
happens if I ping from server to client.

Where got the packages lost??

Generally, when Ping fails the next step is to try TraceRt
or PathPing.

Each of these performs a similar action (to Ping) but arranges
for each router to return an answer -- some routers may refuse
but in general you get a "trace" of the packets.

This trace (or path result) can give you a good idea of which
router or node it losing your packets.
Note: there are no firewallrules active while thesting the connection
(either client nor server sided)!

Many firewall devices/software disallow Ping (i.e., ICMP) EVEN
when they appear disabled.

You might try something more "application" like, perhaps Telnet or
NetCat (nc.exe is NOT a built-in Windows program though) with
a specific and known working service, e.g., a web server from the
client:

telnet Web.Server.IP.Address 80

I would suggest the IP address be used for this to eliminate DNS
as part of your problem.
Thank you!!

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
/var/log/syslog sais:

Jan 3 11:24:30 localhost tinc.consult-it[27717]: Node home
(80.108.85.21 port 655) became reachable
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Got REQ_KEY from home
(80.108.85.21 port 6343): 15 home ciserver
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Sending ANS_KEY to
home (80.108.85.21 port 6343): 16 ciserver home
09005989A8CBF63ABE510FC6A3F1EB515EAF1700629C8E8E 91 64 4 9
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Sending 76 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:24:35 localhost tinc.consult-it[27717]: Received UDP packet
from unknown source 80.108.85.21 port 6655
Jan 3 11:25:40 localhost tinc.consult-it[27717]: Received UDP packet
from unknown source 80.108.85.21 port 6655
Jan 3 11:25:45 localhost tinc.consult-it[27717]: Received UDP packet
from unknown source 80.108.85.21 port 6655
Jan 3 11:26:01 localhost tinc.consult-it[27717]: Sending PING to home
(80.108.85.21 port 6343): 8
Jan 3 11:26:01 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:26:01 localhost tinc.consult-it[27717]: Got PONG from home
(80.108.85.21 port 6343): 9
Jan 3 11:27:34 localhost tinc.consult-it[27717]: Got PING from home
(80.108.85.21 port 6343): 8
Jan 3 11:27:34 localhost tinc.consult-it[27717]: Sending PONG to home
(80.108.85.21 port 6343): 9
Jan 3 11:27:34 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:28:03 localhost tinc.consult-it[27717]: Regenerating
symmetric key
Jan 3 11:28:03 localhost tinc.consult-it[27717]: Sending KEY_CHANGED
to everyone (BROADCAST): 14 364d5d0 ciserver
Jan 3 11:28:03 localhost tinc.consult-it[27717]: Sending 20 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:29:04 localhost tinc.consult-it[27717]: Sending PING to home
(80.108.85.21 port 6343): 8
Jan 3 11:29:04 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:29:04 localhost tinc.consult-it[27717]: Got PONG from home
(80.108.85.21 port 6343): 9
Jan 3 11:30:37 localhost tinc.consult-it[27717]: Got PING from home
(80.108.85.21 port 6343): 8
Jan 3 11:30:37 localhost tinc.consult-it[27717]: Sending PONG to home
(80.108.85.21 port 6343): 9
Jan 3 11:30:37 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:32:07 localhost tinc.consult-it[27717]: Sending PING to home
(80.108.85.21 port 6343): 8
Jan 3 11:32:07 localhost tinc.consult-it[27717]: Sending 2 bytes of
metadata to home (80.108.85.21 port 6343)
Jan 3 11:32:07 localhost tinc.consult-it[27717]: Got PONG from home
(80.108.85.21 port 6343): 9

OK, in fact: I am 80.108.85.21
But the Ping Packages never arrive my windoze client. The equivalent
happens if I ping from server to client.

Where got the packages lost??

Note: there are no firewallrules active while thesting the connection
(either client nor server sided)!

Thank you!!

Christain Maier
 
You will likely get more help with Linux VPNs and their
logs by asking a Linux focused list.

I am not sure where the problem is. on server side (linux) or client
side (Windows)
But you also need to try to be more careful with your
spelling and wording, as well as very specific about
your actual problem.
right, sorry for that! And sorry for my horrable english writing, I'll
give my best!
Generally, when Ping fails the next step is to try TraceRt
or PathPing.

Thanks for this hint, here ist what pathping says:
C:\>pathping 10.1.1.1
Routenverfolgung zu 10.1.1.1 über maximal 30 Abschnitte
0 soundmachine [10.1.1.2]
1 ...
Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 soundmachine [10.1.1.2]
100/ 100 =100% |
1 --- 100/ 100 =100% 0/ 100 = 0% soundmachine [0.0.0.0]

But who is 0.0.0.0??
Many firewall devices/software disallow Ping (i.e., ICMP) EVEN
when they appear disabled.

I can ping the real internet IPs so I thought that here is no problem.
You might try something more "application" like, perhaps Telnet or
NetCat (nc.exe is NOT a built-in Windows program though) with
a specific and known working service, e.g., a web server from the
client:

telnet Web.Server.IP.Address 80
There is no connection possible with telnet.

Ok, lets sum it up:
The Packages arrive at serverside cause there is the syslog entry.
If my sylsog dosn't lie the server send the ping to my client
pathping colud not realy help -or does it?

Hmm .. I would say: The arrived package from my server is not
recognised by my client an get droped.

To make another test I edited the Key Files to occour an error because
of unmatching keys. Ping my server one more time and yea(!) in my Win
Eventlog I can see now the following:
tinc: Bogus data received from ciserver (83.65.166.XXX port 655).

And in my server syslog I can see:
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Connection from
80.108.85.21 port 6181
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending ID to (null)
(80.108.85.21 port 6181): 0 ciserver 17
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending 14 bytes of
metadata to (null) (80.108.85.21 port 6181)
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Got ID from (null)
(80.108.85.21 port 6181): 0 home 17
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending METAKEY to
home (80.108.85.21 port 6181): 1 94 64 0 0
9B0AC9756F4BEC31D88E8B00C70AE1EB4B20BB2A3CA42C8CFEECA61EB2CE52A46E554E0CA3CF687637E209F65904E97E140D3E9AEAD353168B498C4BB5191BC5C9A53954E2C54D36E24A0D090C9DCBA2D8466FC501B3463B8E52B60561D2FC95C31BF2A8360E690FD70461FB47D32AA6285AE7FFC81DCEDAA96A4D41220F4490
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending 269 bytes of
metadata to home (80.108.85.21 port 6181)
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Got METAKEY from home
(80.108.85.21 port 6181): 1 94 64 0 0
88E689854A6624976FC86381EE70D46EA5053197C2B42D18D524954EAAE2816D62F7603AF9573FE8365B0649C60235C89CC5A974106A0F40DE9C01F4BE85DE3C454A78DFE9CB26185B0899256C27B90024713B5D927D8D6F5A5727BFE18D20E0E741B2778859E9C6B2E4E684F5FA0DA8ED06F3B88268DABB42454AB3C5C927EC
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending CHALLENGE to
home (80.108.85.21 port 6181): 2
EEB38A2E0F0627C6E1D38314113BDBDBFC6676534E910F390FF1C24F09029C49BACF8227194CCA8C362F135AEFFCC5DADD20A7CA36E926A58507FFA922C0508342AA395A22F5460A147B6A65D20EBCE969B894651CE71E8F53D34FB8EBE267723F186095FF7E8E150D634892E5A4F2C3A260DF158134C12DFAD1C77E2C5B4F6B
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending 259 bytes of
metadata to home (80.108.85.21 port 6181)
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Got CHALLENGE from
home (80.108.85.21 port 6181): 2
73AC3A3ECD7E558DEBF25D9E00DDEBA7133A2D203542B1501AD56B7883CFA5E32C899E940453338F257734142FF3EACB522CE8534211C2570DAD622DDA46C87C096921299AA9CC4B4915DDDA9A11F3412399EEE7B6B5887679EC1D5E5C67D3DA6ED0CC840544724E5E8060A1261509DE232BC94AFD6A7B8EAF8512D3F3ED424A
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending CHAL_REPLY to
home (80.108.85.21 port 6181): 3
E06B5E5FFE0F0969852B43AB11846495EB266656
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Sending 43 bytes of
metadata to home (80.108.85.21 port 6181)
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Connection closed by
home (80.108.85.21 port 6181)
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Closing connection
with home (80.108.85.21 port 6181)
Jan 4 16:06:09 localhost tinc.consult-it[4831]: Purging unreachable
nodes

So the Client closed the connection. Do you know more about tinc and
were my mistakes are?

Thx!
Christian Maier
 
Christian Maier said:
You will likely get more help with Linux VPNs and their
logs by asking a Linux focused list.

I am not sure where the problem is. on server side (linux) or client
side (Windows)
But you also need to try to be more careful with your
spelling and wording, as well as very specific about
your actual problem.
right, sorry for that! And sorry for my horrable english writing, I'll
give my best!

Mein Deutsh ist nicht sehr gut auch.
Generally, when Ping fails the next step is to try TraceRt
or PathPing.

Thanks for this hint, here ist what pathping says:
C:\>pathping 10.1.1.1
Routenverfolgung zu 10.1.1.1 über maximal 30 Abschnitte
0 soundmachine [10.1.1.2]
1 ...
Berechnung der Statistiken dauert ca. 25 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 soundmachine [10.1.1.2]
100/ 100 =100% |
1 --- 100/ 100 =100% 0/ 100 = 0% soundmachine [0.0.0.0]

But who is 0.0.0.0??

Ich weise nicht aber... Check 10.1.1.2 AND the next hop.
Many firewall devices/software disallow Ping (i.e., ICMP) EVEN
when they appear disabled.

I can ping the real internet IPs so I thought that here is no problem.

Probably ok then.

But notice your routing may not allow for routing the correct
address but might still allow for routing other addresses.
There is no connection possible with telnet.

Be certain you mean "with Telnet to some SPECIFIC service"
(like WWW server using HTTP).

You likely have no Telnet daemon (or server) running so just
saying "with telnet" is ambiguous.
Ok, lets sum it up:
The Packages arrive at serverside cause there is the syslog entry.

So the problem is at the server OR on the way back.
If my sylsog dosn't lie the server send the ping to my client
pathping colud not realy help -or does it?

Vielleicht ja, vielleicht nein.
Hmm .. I would say: The arrived package from my server is not
recognised by my client an get droped.

Maybe some router on the RETURN path is misconfigured.

Maybe routing TO the server works but not routing FROM the
server. The return path can fail while the outbound path works.

A common mistake is to overlook the routes THROUGH the
VPN.
 
THX for all!

I gave it up, I'll install a BSD firewall/router with vpn in front of
my server - hope this works.

Thank you!

Christian
 
Back
Top