[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Trying to understand...


  • Subject: Re: [Openvpn-users] Trying to understand...
  • From: Stefan Lamby <slamby@xxxxxx>
  • Date: Tue, 11 Sep 2007 22:16:32 +0200

Erich,

I did all the things you mentioned without doing one single step ahead.
The outputs are listed below, maybe it helps for a next conclusion.

I appreciate your help a lot - do not get me wrong. I am asking myself,
if you did read my mail or just answered in a "standard way" like you
did to my post to the list about 1 month ago with the same problem.
Meanwhile I read a lot since I didnt want to bother you all with my
problem.

The reason I mentioned the "standard way" is because I wrote in my
initial post, that without running the firewall I can get a connection
to that 192.168.10.25 client. So surely the prob is just based on
firewall policies.

How will I be able to track down the problem?

Thanks
Stefan

Erich Titl schrieb:
> Hi
>
> Stefan Lamby schrieb:
>   
>> Hi.
>>
>> I have been watching this list for a while and also read the manual.
>> Trying to solve this for a month now, but dont understand:
>>
>> I am using openvpn in the standard configuration with dev=tun, udp on
>> port 1194.
>>
>> My server running openvpn is a linux box, running SuSE linux with
>> SuSEfirewall2 running.
>>
>> The intention is to remote control clients via tightvnc.
>>
>> !!!!!! When I shut down my firewall script, everything is running, so it is
>> obvious that the problem is caused by the firewall !!!!
>>
>> How can I find out, where exactly my problem is?
>>     
>
> Oh my, if we would get a dime for everyone who runs into the same old
> problem. I guess we are in need of a comprehensive TCP debugging course.
>   
That would be great and also would save a lot of questions... Maybe I
will write one if I am through all that.

>  The simple answer is, follow the packet trail and look into the
> firewall logs.
>   
tail -f /var/log/messages during trying to contact the 192.168.10.25
client gave no output at all. SuSEfirewall2 is configured to use this
file for report. That doesnt help.
>   
>> I used tcpdump -i tun0 at the server and when I like to get a connection
>> from my openvpn client to the tightvnc server (the client 192.168.10.25
>> behind the openvpn server) the output is as follows: 
>>     
>
> Looks like some packets made it through the tunnel at least
>
> 19:17:47.724969 IP 10.8.0.6.citriximaclient > 192.168.10.25.5900: S
> 543787865:543787865(0)
> win 16384 <mss 1118,nop,nop,sackOK>
>
>   
>> Please help me understand, I am not an expert to iptables but I got the
>> basics.
>>     
>
> Time, source address and port, destination address and port, some IP
> stuff, tcp window size, mss size, and tcp flags
>   
What do you mean with: Time, source adress..... and so on?
> The questions here are:
> did this packet make it to 192.168.10.25 or not, was it replied to and
> did 192.168.10.25 have a reasonable route to 10.8.0.6. Your tcpdump
> entry does not give us an answer as it only looks at the tun interface.
>
> To answer the first question first find which interface leads to
> 192.168.10.25
>
> 'ip route get 192.168.10.25'
> should reveal it.
>   

that is the answer from ip route get 192.168.10.25: 192.168.10.25 dev
eth1 src 192.168.10.1
> Then do a tcpdump on that interface and have a look for the packet. If
> you cannot see it you need to review your firewall rules.
>   
This is the output from: tcpdump -i eth1 when I try to connect to that
client.

21:36:05.190854 IP 10.8.0.6.ltctcp > 192.168.10.25.5900: S
2852988334:2852988334(0) win 16384 <mss 1118,nop,nop,sackOK>
21:36:05.191120 IP 192.168.10.25.5900 > 10.8.0.6.ltctcp: S
2659819560:2659819560(0) ack 2852988335 win 65535 <mss 1460,nop,nop,sackOK>
21:36:08.159141 IP 192.168.10.25.5900 > 10.8.0.6.ltctcp: S
2659819560:2659819560(0) ack 2852988335 win 65535 <mss 1460,nop,nop,sackOK>
21:36:08.162598 IP 10.8.0.6.ltctcp > 192.168.10.25.5900: S
2852988334:2852988334(0) win 16384 <mss 1118,nop,nop,sackOK>
21:36:08.162887 IP 192.168.10.25.5900 > 10.8.0.6.ltctcp: . ack 1 win 65535
21:36:10.189690 arp who-has 192.168.10.25 tell lxba2.bauer
21:36:10.189943 arp reply 192.168.10.25 is-at 00:19:d1:41:82:f7
21:36:14.174899 IP 192.168.10.25.5900 > 10.8.0.6.ltctcp: S
2659819560:2659819560(0) ack 2852988335 win 65535 <mss 1460,nop,nop,sackOK>
21:36:14.199896 IP 10.8.0.6.ltctcp > 192.168.10.25.5900: S
2852988334:2852988334(0) win 16384 <mss 1118,nop,nop,sackOK>
21:36:14.200133 IP 192.168.10.25.5900 > 10.8.0.6.ltctcp: . ack 1 win 65535

The connection result failed - just to complete this sequence.



Here is the output with firewall disabled and only turning on
ip-forwarding by echo 1 > /proc/sys/net/ipv4/ip_forward.


22:02:07.339507 IP 10.8.0.6.opscenter > 192.168.10.25.5900: S
3520534552:3520534552(0) win 16384 <mss 1118,nop,nop,sackOK>
22:02:07.339822 IP 192.168.10.25.5900 > 10.8.0.6.opscenter: S
2448231091:2448231091(0) ack 3520534553 win 65535 <mss 1460,nop,nop,sackOK>
22:02:07.456298 IP 10.8.0.6.opscenter > 192.168.10.25.5900: . ack 1 win
16770
22:02:07.456935 IP 192.168.10.25.5900 > 10.8.0.6.opscenter: P 1:13(12)
ack 1 win 65535
22:02:07.584041 IP 10.8.0.6.opscenter > 192.168.10.25.5900: P 1:13(12)
ack 13 win 16758
22:02:07.584366 IP 192.168.10.25.5900 > 10.8.0.6.opscenter: P 13:17(4)
ack 13 win 65523
22:02:07.584445 IP 192.168.10.25.5900 > 10.8.0.6.opscenter: P 17:33(16)
ack 13 win 65523
22:02:07.715849 IP 10.8.0.6.opscenter > 192.168.10.25.5900: . ack 33 win
16738

22:05:07.655016 IP 10.8.0.6.netplay-port2 > 192.168.10.25.5900: P
13:29(16) ack 33 win 16738
22:05:07.655397 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: P
33:37(4) ack 29 win 65507
22:05:07.776029 IP 10.8.0.6.netplay-port2 > 192.168.10.25.5900: P
29:30(1) ack 37 win 16734
22:05:07.792945 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: P
37:61(24) ack 30 win 65506
22:05:07.792953 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: P
61:67(6) ack 30 win 65506
22:05:07.923083 IP 10.8.0.6.netplay-port2 > 192.168.10.25.5900: . ack 67
win 16704
22:05:07.927528 IP 10.8.0.6.netplay-port2 > 192.168.10.25.5900: P
30:50(20) ack 67 win 16704
22:05:07.932022 IP 10.8.0.6.netplay-port2 > 192.168.10.25.5900: P
50:78(28) ack 67 win 16704
22:05:07.932368 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: . ack 78
win 65458
22:05:07.935008 IP 10.8.0.6.netplay-port2 > 192.168.10.25.5900: P
78:88(10) ack 67 win 16704
22:05:07.967472 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: P
67:71(4) ack 88 win 65448
22:05:07.968472 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
71:1189(1118) ack 88 win 65448
22:05:07.969347 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
1189:2307(1118) ack 88 win 65448
22:05:07.970347 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
2307:3425(1118) ack 88 win 65448
22:05:07.971346 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
3425:4543(1118) ack 88 win 65448
22:05:07.972220 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
4543:5661(1118) ack 88 win 65448
22:05:08.172385 IP 10.8.0.6.netplay-port2 > 192.168.10.25.5900: . ack
1189 win 16770
22:05:08.173608 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
5661:6779(1118) ack 88 win 65448
22:05:08.174607 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
6779:7897(1118) ack 88 win 65448
22:05:08.175607 IP 192.168.10.25.5900 > 10.8.0.6.netplay-port2: .
7897:9015(1118) ack 88 win 65448

> If you have difficulties to decipher the tcpdump output, then save it
> with tcpdump ..... -w filename and open it with a tool like wireshark,
> which will break up the packet for you.
>
> cheers
>
> Erich
>
>   

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users