[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: Wed, 12 Sep 2007 22:47:48 +0200

Hi Erich,
hi list.

The problem is solved.
This was the solution:

In the documentation (HowTo 2.0) there is mentioned to make sure that
the TUN/TAP interface is not firewalled. This is a link to
http://openvpn.net/faq.html#firewall where serveral rules are listed to
accomplish this.

These are the rules (#1 and #2):

1) iptables -A INPUT -i tun+ -j ACCEPT
means: let all packages meant for tun0, tun1, etc. pass. That is right
and needs to be there. This was not causing the problem and is still
applied in the rule set I use.

Note that in case the input chain from iptables meets another rule which
is handling the -i tun0..(n-1) before yours can be applied, it could be
that you get in trouble. This could happen if this earlier met rule
states to drop packages. So appending is not always a good way because
the rule wont make it to the top of the chain. The order of rules can be
inspected by using 'iptables -L' or 'iptables-save'. Pipe it in a file -
it could be a lot of output.

2) iptables -A FORWARD -i tun+ -j ACCEPT
Explained in the FAQ with: Allow TUN interface connections to be
forwarded through other interfaces.
This was causing the error which took me hours to find...
It is right that traffic, meeting the FORWARD chain with -i(nput) tun+
will be accepted. The first missinterpretation is done often and affects
the -i and the -o parameters together with FORWARDing rules: -i DOES NOT
MEAN interface, input and -o(utput) is meant instead.

So what the above rule allows is: Let pass all packages with input
tun0...(n-1).

The other direction, when tun+ is used the way back, means if it is the
output, is not covered by this rule and lead to a very tricky behavior
on my SuSE linux box, which is all in one machine: Gateway, Router,
OpenVPN server, Firewall and so on.

The only solution to get this running was to add these TWO (especially
the missing 2nd) policies:
iptables -A FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -A FORWARD -o tun0 -i eth1 -j ACCEPT

I applied exact rules by defining exactly what I want to have: If input
is tun0 and output is eth1, accept and vice versa. Eth1 is my internal
interface. So does tun0, which is also applied to the internal zone.

It should be mentioned that I am running the SuSEfirewall2. I used
/etc/sysconfig/scripts/SuSEfirewall2-custom which can be included at the
very end of your main firewall configuration script to make the changes
permanent.


Something else that might be very usefull for newbies:

If you are running in trouble with your openvpn setup, you are well
adviced to check on which side the error occurs: The often mentioned
routing issue or the firewall configuration.

It is pretty easy to check if the firewall is causing the problems by
disabling it. For suse you just have to '/sbin/SuSEfirewall2 stop' stop
it. Now if you think you can test and see if it is gonna work, you are
WRONG!!! Why? Because if you stop the firewall, the script will be
unloaded and this means (at least for suse), your IP-FORWARDING will be
set to NO or 0, which means it is not enabled any more. You can check
the status with 'cat /proc/sys/net/ipv4/ip_forward'. The output at your
console will be 0 or 1, which means DISABLED(0) or enabled(1). With ip
forwarding disabled, your openvpn WILL NEVER WORK.
So you might want to enable it, using 'echo 1 >
/proc/sys/net/ipv4/ip_forward', which will write a '1' in that file.



Thanks to Eric anyway, he inspired me to test drive those freaky tools
like ethereal (now wireshark) and it helped me to understand what is
going on at my network a little more. If you ever try it, DO NOT miss
this link: http://www.packet-level.com/traces/index.htm , which is
reached from the wireshark wiki and provides some good learning examples
for network traffic. It covers a simple TCP Handshake Process, Ping
Standard Operations, examples for wrong network setups and a lot more.

Hope this helps somebody else.

Thanks
Stefan


P.S.: There is still a question left... Maybe someone could pick it up...
I am not satisfied at all since I didnt understand, why this
SuSEfirewall2-script at the end denies forwarding for tun0. Does this
make sense at all even it is an internal interface? Thinking about it
again makes me feel that it could make sense as a security issue to deny
everything by default. So you do not have wholes in your firewall.

FWBuilder is a far better solution to face the firewall settings.



Erich Titl schrieb:
> 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 192.168.10.25 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 192.168.10.25
>> client gave no output at all. SuSEfirewall2 is configured to use this
>> file for report. That doesnt help.
>>     
>
> Bad....
>
>   
>>>   
>>>       
>>>> 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?
>>     
>
> 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 10.8.0.6.ltctcp > 192.168.10.25.5900: 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 192.168.10.25.5900 > 10.8.0.6.ltctcp: 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 192.168.10.25.5900 > 10.8.0.6.ltctcp: 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 10.8.0.6.ltctcp > 192.168.10.25.5900: S
>> 2852988334:2852988334(0) win 16384 <mss 1118,nop,nop,sackOK>
>>     
>
> Another request from the VNC client
>
>   
>> 21:36:08.162887 IP 192.168.10.25.5900 > 10.8.0.6.ltctcp: . ack 1 win 65535
>>     
>
> and a reply from the VNC server
>
>   
>> 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>
>>     
>
> again a reply from the server
>
>   
>> 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>
>>     
>
> request again
>
>   
>> 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.
>>     
>
> 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!!
> FW_SERVICES_EXT_IP=""
>
> 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.
>
> cheers
>
> Erich
>
>   

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