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

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

  • Subject: Re: [Openvpn-users] Trying to understand...
  • From: Erich Titl <erich.titl@xxxxxxxx>
  • Date: Tue, 11 Sep 2007 23:22:17 +0200

Stefan Lamby schrieb:
> Erich,

> 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 client. So surely the prob is just based on
> firewall policies.

the firewall is certainly an issue, let's hope it is the only one

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

These are the fields in your tcpdump output.


> 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 > S
> 2852988334:2852988334(0) win 16384 <mss 1118,nop,nop,sackOK>

OK the packet made it to eth1, so it is routed and not intercepted by
the firewall

> 21:36:05.191120 IP > S
> 2659819560:2659819560(0) ack 2852988335 win 65535 <mss 1460,nop,nop,sackOK>

And here we see a packet in the opposite direction, so it appears that
the VNC application is willing to talk to us.

> 21:36:08.159141 IP > S
> 2659819560:2659819560(0) ack 2852988335 win 65535 <mss 1460,nop,nop,sackOK>

But it appears that the packet did not make it back completely, that is
why the VNC repeats its reply.

> 21:36:08.162598 IP > S
> 2852988334:2852988334(0) win 16384 <mss 1118,nop,nop,sackOK>

Another request from the VNC client

> 21:36:08.162887 IP > . ack 1 win 65535

and a reply from the VNC server

> 21:36:10.189690 arp who-has tell lxba2.bauer
> 21:36:10.189943 arp reply is-at 00:19:d1:41:82:f7

> 21:36:14.174899 IP > S
> 2659819560:2659819560(0) ack 2852988335 win 65535 <mss 1460,nop,nop,sackOK>

again a reply from the server

> 21:36:14.199896 IP > S
> 2852988334:2852988334(0) win 16384 <mss 1118,nop,nop,sackOK>

request again

> 21:36:14.200133 IP > . ack 1 win 65535
> The connection result failed - just to complete this sequence.

I presume your firewall is blocking traffic from eth1 to the tun interface.

Had you done a tcpdump on the tun interface at the same time you could
now correlate the output, you would probably see, that the packets did
not show up at the tun interface.

You need to inspect your firewall rules. I have no SuSE firewall
running, I prefer shorewall or fwb, so I can only guess on your set up.
One thing I could imagine is the setting of

## Type:        string
# For VPN/Routing which END at the firewall!!

I hate those murky comments

Try to correlate the tcpdump output from eth1 with tun. Again I advise
you to collect the data and analyse it with wireshark. It is a lot
easier to understand than simple tcpdump output.

The other tcpdump just shows a working connection, nothing of much
interest there.

OpenVPN mailing lists