Topic: openvpn on 6.01

[hanscees]

Hi,

has anybody installed openvpn server on sme 6.01? The new version 2.0 seems very powerfull indeed. Ther client now works on recent windows hosts using ip=-routing with tun devices.

any help would be apreciated.

Hans-Cees

[salesman]

Yes, works great!!!!

regards
Michael

[Knuddi]

I am finalizing a Howto for Win2k/XP GUI client access to the SME Server.

If you have the balls then try out out from:

http://sme.swerts-knudsen.dk/howtos/howto_30.htm

Let me know whether it works as expected.

[hanscees]

I will try this tonight. having a howto on demand is truly wonderfull!

Only I want to use a tun setup with routing.
I will try to change your configs to the tun scenario. But if you already know what things I have to change to do that please let me know.

I take it the tls-scenario still works the same?


hc

[hanscees]

Hi,

I have trouble getting the udp port 1194 in.

I installed
[root@sme home]# rpm -Uvh http://sme.swerts-knudsen.dk/downloads/dmc-mitel-portopening-0.0.1-4.noarch.rpm

I see the following:
Nov 16 14:34:53 vmw kernel: denylog:IN=eth1 OUT= MAC=00:50:56:40:00:b8:00:40:95:30:11:d4:08:00 SRC=192.168.0.2 DST=192.168.0.114 LEN=42 TOS=0x00 PREC=0x00 TTL=128 ID=17833 PROTO=UDP SPT=1194 DPT=1194 LEN=22


The outside for me in this test is 192.168.0.114.
I see no iptables rule with port 1194 . So I guess the rpm to let in this traffic has a problem.

Hans-Cees

[Appesteijn]

I've no problem with the port-opening rpm. (SME5.6) But I get the following error:

Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Nov 17 20:58:42 server-one openvpn[3565]: 194.109.xxx.xxx:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Nov 17 20:58:42 server-one openvpn[3565]: 194.109.xxx.xxx:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
Nov 17 20:58:42 server-one openvpn[3565]: 194.109.xxx.xxx:1194 [Client] Peer Connection Initiated with 194.109.xxx.xxx:1194
Nov 17 20:58:43 server-one openvpn[3565]: 194.109.xxx.xxx:1194 PUSH: Received control message: 'PUSH_REQUEST'
Nov 17 20:58:43 server-one openvpn[3565]: 194.109.xxx.xxx:1194 SENT CONTROL [Client]: 'AUTH_FAILED' (status=1)

And then read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Is this because the 'connector' is behind a NAT and also has to forward port 1194 ?

[hanscees]

I got it working at last.

The howto is very good. The only thing that really got me stuck is that on my windows 2000 box the tap interface did not get an ip address.
I could see with "ipconfig /all" that it had an dhcpserver address but no ip.
This was solved by reading the man page and finding the option:
ip-win32 ipapi
in my client xx.ovpn configfile.

I also deleted the lines in the server conf about auth and logoff.sh.


My whole setup, using routing, and not bridging,  is like below:


server:
================================
#TUN setup (routing not bridging)
mode server
duplicate-cn
port 1194
dev tun #in stead of dev tap
tls-server

dh dh1024.pem
ca ca.crt
cert SERVER.crt
key SERVER.key

#here authentication. Whithout it this
#setup is not safe: your laptop might
#be stolen.
#you could put the client keys on i-keys
#with pincode, or use a passphrase in the
#client ssl keys.
#the two lines below use password authentication.
#not perfect but better than nothing any time.
auth-user-pass-verify ./validate.sh via-env
client-disconnect ./logoff.sh

ifconfig 192.168.100.1 192.168.100.2

# IP range for openvpn clients
ifconfig-pool 192.168.100.5 192.168.100.200

mtu-test
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
ping 10
ping-restart 120
#route to be established on the server
route-up "route delete -net 192.168.100.0/24"
route-up "route add -net 192.168.100.0/24 tun0"
#route to push to the other side
push "route 172.16.1.0 255.255.255.0"
push "ping 10"
push "ping-restart 60"
push "dhcp-option DOMAIN hansceess.net"             # #push the DNS domain suffix
push "dhcp-option DNS 172.16.1.1"       #push DNS #entries to openvpn client
push "route 192.168.100.1"

comp-lzo
status-version 2
status openvpn-status.log
verb 5
===========================================


config on the windows 2000 client:
=======================================
port 1194
dev tun
remote 192.168.0.114
tls-client
auth-user-pass
ca ca.crt
cert CLIENT.crt
key CLIENT.key

mtu-test
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
pull
#ifconfig 192.168.100.2 192.168.100.1
#ip-win32 ipapi|manual|dynamic|netsh (see
#man page, use #when ip address on interface
#does not appear, but dhcp server
#is visable in ipconfig /all)
ip-win32 ipapi
comp-lzo
verb 5
=====================================

This works for me. In iptables on the server you need rules like these:
 /sbin/iptables --append FORWARD -i tun0 -j ACCEPT

To let traffic pass through the VPN box to networks behind it.

Hans-Cees

[duncan]

=====================================

This works for me. In iptables on the server you need rules like these:
 /sbin/iptables --append FORWARD -i tun0 -j ACCEPT

To let traffic pass through the VPN box to networks behind it.

Hans-Cees

Hi,

There is no requirement for this. This is achieved by adding the remote network (in the case of Lan - Lan vpns) as well as the p-t-p network in "local networks".

Regards Duncan

[hanscees]

=====================================

This works for me. In iptables on the server you need rules like these:
 /sbin/iptables --append FORWARD -i tun0 -j ACCEPT

To let traffic pass through the VPN box to networks behind it.

Hans-Cees

Hi,

There is no requirement for this. This is achieved by adding the remote network (in the case of Lan - Lan vpns) as well as the p-t-p network in "local networks".

Regards Duncan

I was talking generally. I do not use the sme-iptables rules, but a set of my own. Iptables-wise such rules are needed. Also rules to let in port 1194 (I think it was 1194).

What astonished me was that if you use "iptables-input-accept -i tun0", you let the tunnel-clients into the open-vpn-server, at eth0 (intranet interface), even if you block forward. That is counter-intuitive. You would expect traffic from tun0 to go through a forward chain to eth0, and then the input chain of your internal interface, eth0. Not so! So just block input -i tun0 and no traffic will get into your openvpn server,


I find the sme iptables rules too unclear to depend on (personnaly).

Hans-Cees

[Appesteijn]

With the updated HowTo made by Knuddi, it also worked on my SME5.6. I'm still trying to get the Networkneighbourhood and multi-player-games working. Anyway thanx alot!

[Appesteijn]

Does a connecting client has to be assigned a ip-adres in another ip-range than the existing LAN-ip-range?
I'm trying to get some LAN games running and would like to try if it would make any difference wether the client is in my same ip-range. Or would it give complications with regard to routing?
Also the client doesn't see my computers in his network-neighbourhood. I'm seeing his computer in my neighbourhood. But that would be a Netbios thing I guess.

[cydonia]

I got this error when i tried to start openvpn:

Starting openvpn: sh: ./openvpn.up: /bin/sh: bad interpreter: Permission denied



What have i left out...?

[Appesteijn]

Make sure that you've done 'chmod 700 openvpn.up'

[cydonia]

Make sure that you've done 'chmod 700 openvpn.up'

thanks, thought i had done that.  Working fine now.

Another question though, what is the difference/advantage/disadvantage between OpenVPN & Freeswan?

On my previous SME box i used Freeswan and it seemed to work fine, using the built in WinXP VPN configuration settings.

I am trying this to try something different, but curious to know how they differ.

[Appesteijn]

If you want to play games over you VPN, you've to bridge your VPN (tap0) with your LAN (eth0). OpenVPN includes a bridge startup script that worked for me.(/usr/share/openvpn/sample-scripts) You only have to install bridge-utils-0.9.6-46.i586.rpm (www.rpmfind.net) If anybody wants it I can post my config files.