|
|
Thomas Heidemann wrote:
> Hi Erich,
> sorry for not posting such a long time but I was out over the weekend.
> Lets get's back to my problem....
>
> In 2.0 it must be tcp-server or tcp-client. tcp alone is not sufficient.
> lport defined the local porto which openvpn has to bind to. I didn't specify the remote port (of the client) becausethe server does not know, from where the connection comes. Also some http proxies might use other ports.
>
> Here are some tcpdumps which show my problem after connection initialisation while I pinged the server (10.8.0.1):
>
> Server (eth0):
> 18:24:37.108929 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 0
> 18:24:37.109462 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 52
> 18:24:37.175273 IP 85.216.23.103.16022 > 145.253.90.49.443: tcp 0
> 18:24:37.175375 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 350
> 18:24:37.201236 IP 85.216.23.103.16022 > 145.253.90.49.443: tcp 0
> 18:24:39.316469 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144 <-- Connection initialised here!
> 18:24:39.552296 IP 145.253.90.49.443 > 85.216.23.103.16022: tcp 144
...
This is weird, all this seems to indicate traffic _from_ the server to
the client.
>
> Server (tun0):
> - nothing -
>
> Client (eth1):
> 18:24:37.103850 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 134
> 18:24:37.137511 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 0
> 18:24:37.138007 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 52
> 18:24:37.177338 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 0
> 18:24:37.205175 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 350
> 18:24:37.205299 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 0
> 18:24:39.344744 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144 <-- Connection initialised here!
> 18:24:39.580828 IP 145.253.90.49.443 > 192.168.1.100.16022: tcp 144
...
>
> Client (tun0):
> 18:24:38.101454 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
This is completely wild. Why does the client send traffic to
145.253.90.49 through the tunnel. We should only see. traffic in the
10.8.0.0/24 range pass through the tunnel. The client should _not_ use
its _real_ address to access the server. This is not normal OpenVPN traffic.
> 18:24:39.045491 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
> 18:24:40.933656 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
Now here this is more reasonable ...
> 18:24:43.156217 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 1, length 64
> 18:24:44.165874 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 2, length 64
> 18:24:44.709906 IP 192.168.1.100.16022 > 145.253.90.49.443: tcp 52
It appears that in your case tunnel traffic _and_ tunneled traffic is
interspersed
> 18:24:45.167015 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 3, length 64
> 18:24:46.166043 IP 10.8.0.10 > 10.8.0.1: ICMP echo request, id 35898, seq 4, length 64
...
>
> Both clocks (server and client) are in sync!
>
> Routing table of client after initialisation:
> Kernel IP Routentabelle
> Ziel Router Genmask Flags Metric Ref Use Iface
> 10.8.0.1 10.8.0.9 255.255.255.255 UGH 0 0 0 tun0
> 10.8.0.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
> 145.253.90.32 10.8.0.9 255.255.255.224 UG 0 0 0 tun0
And here is the reason why....
The route to 145.253.90.32/27 covers/hides the server address
145.253.90.49. Your routing is flawed.
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 192.168.11.0 10.8.0.9 255.255.255.0 UG 0 0 0 tun0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> 0.0.0.0 192.168.1.10 0.0.0.0 UG 0 0 0 eth1
>
> So the routes are correct I think.
I don't think so.
cheers
Erich
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-------------------------------------------------------------------------
Get stuff done quickly with pre-integrated technology to make your job easier _______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|