check Config and Routing Problem

niclas.mueller

Hey Dudes,

I've a installation of OpenVPN ans tun-mode and it's running, but i would like to optimize this setup.
Also I've a problem, hat my client try to add routes twice.

I start with my server.conf

# Port
port 1196

# TCP oder UDP?
proto udp

# tun oder tap?
# Das tun Device erstellt einen IP Tunnel,
# während das tap Device einen Ethernet Tunnel erstellt.
dev tun

# Die ermittelte mtu für das tun Interface.
# Wir fügen die Optionen fragment und
# mssfix hinzu, um ein Aushandeln der
# Paketgroessen zu ermoeglichen

tun-mtu 1492
fragment 1300
mssfix

# Die Pfade zu den Keys und Zertifikaten.
# Ich kopiere die Pärchen später in das
# openvpn Verzeichnis, um Wirrwarr vorzubeugen.
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key


# der Pfad zu den Diffie-Hellmann Parametern.
# Auch diese werde ich später ins openvpn
# Verzeichnis kopieren.
dh ./easy-rsa2/keys/dh1024.pem


# Durch die Angabe von server veranlassen
# wir openvpn im Servermodus zu lauern.
# Hier übergeben wir auch den Adressbereich
# und die Netzwerkmaske für das virtuelle
# Netzwerk. Der Server wird automatisch
#auf der ersten IP lauschen - also 10.8.0.1

server 10.100.0.0 255.255.255.0

# Wir können einen Pool für die Virtuellen
# Adressen angeben. Falls ein Client die
# Verbindung beendet, bekommt er bei der
# nächsten Verbindung automatisch die selbe
# IP zugewiesen.
ifconfig-pool-persist ipp.txt

# Mit dem push Befehl können wir die
# Clients veranlassen ihre Routing Tabellen
# automatisch beim Verbindungsaufbau neu
# zu schreiben. Wir veranlassen also die Clients
# die Route in den Adressbereich
# 192.168.0.0 automatisch über vpn zu routen
#push "route 192.168.122.0 255.255.0.0"



push "route 10.0.0.0 255.255.0.0"
route 10.0.0.0 255.255.0.0

push "route 10.1.0.0 255.255.0.0"
route 10.1.0.0 255.255.0.0

push "route 10.2.0.0 255.255.0.0"
route 10.2.0.0 255.255.0.0

push "route 10.3.0.0 255.255.0.0"
route 10.3.0.0 255.255.0.0

push "route 10.4.0.0 255.255.0.0"
route 10.4.0.0 255.255.0.0

push "route 10.5.0.0 255.255.0.0"
route 10.5.0.0 255.255.0.0

push "route 192.168.178.0 255.255.255.0"
route 192.168.178.0 255.255.255.0



# Mit keepalive können wir uns
# informieren, ob die Gegenstelle noch
# erreichbar ist. Wir setzen alle 10 Sekunden
# ein ping ähnliches Paket ab und gehen
# davon aus, dass die Gegenstelle weg ist,
# wenn nach 120 Sekunden keine Antwort kommt.
keepalive 10 120

# Unsere Authentifizierungsmethode
auth SHA1

# Unsere Verschlüsselungsmethode
cipher AES-256-CBC

# Wir wollen komprimierten Datenverkehr
comp-lzo

# Wir reduzieren die Rechte, mit dem der
# Server läuft nach dem Verbindungsaufbau.
# Dies wird allerdings zur Folge haben, dass er keine Berechtigung mehr hat die
# Routing Tabelle in den ursprünglichen
# Zustand zu versetzen, was hier aber kein
# Problem darstellt.
user nobody
#group nobody

# Die persist Optionen werden die Keys
# und Zertifikate im Speicher behalten,
# so dass sie auch noch gelesen werden
# können nachdem Gruppe und User
# gewechselt wurden.
persist-key
persist-tun

# Für unsere Versuche setzen wir die Geschwätzigkeit
# auf Level 3
verb 3
client-config-dir ccd

client config looks like this

client
float
dev tun
tun-mtu 1492
fragment 1300
mssfix
proto udp
remote XXXXX 1196
#tls-remote server
ca ca.crt
cert nb001.crt
key nb001.key
dh dh1024.pem
auth SHA1
cipher aes-256-cbc
nobind
comp-lzo
persist-key
persist-tun
verb 3
pull

nb001 ccd config is this

push "route 10.100.0.0 255.255.0.0"
route 10.100.0.0 255.255.0.0
push "route 10.250.0.0 255.255.0.0"
route 10.250.0.0 255.255.0.0

push "route 10.0.0.0 255.255.0.0"
route 10.0.0.0 255.255.0.0
push "route 10.1.0.0 255.255.0.0"
route 10.1.0.0 255.255.0.0
push "route 10.2.0.0 255.255.0.0"
route 10.2.0.0 255.255.0.0
push "route 10.3.0.0 255.255.0.0"
route 10.3.0.0 255.255.0.0
push "route 10.4.0.0 255.255.0.0"
route 10.4.0.0 255.255.0.0
push "route 10.5.0.0 255.255.0.0"
route 10.5.0.0 255.255.0.0
push "route 192.168.178.0 255.255.255.0"
route 192.168.178.0 255.255.255.0


push "dhcp-option DNS 10.250.10.1"
push "dhcp-option DNS 10.0.10.1"
push "dhcp-option DOMAIN ms-dc.network"
push "dhcp-option WINS 10.250.10.1"
push "dhcp-option WINS 10.0.10.1"

So some questions:

In the Server conf stands routes whitch the SERVER should apply and in client config (ccd) the settings the client should apply is'nt it so ?

And is my setup clean and secure?

I've enabled on every side to side server MASQUARADING and sysctl.conf net.ipv4.ip_forward=1 .

Star Root Server hat 100MBits/100MBits and Clients have from 6/0,5 -> 100/5 Connection.

Thanks!

mwandelaar

niclas.mueller wroteSo some questions:

In the Server conf stands routes whitch the SERVER should apply and in client config (ccd) the settings the client should apply is'nt it so ?

That's not entirely true. Quite a lot of options from the server-conf get pushed to the client or explicit forced upon connect. For example: You are using

# Unsere Authentifizierungsmethode
auth SHA1

# Unsere Verschlüsselungsmethode
cipher AES-256-CBC

which is enforced upon connect, for both client and server.

Besides that, you are using in the server-conf quite a lot of "push route" lines. These are pushed to the client.
If you add them to the ccd-file also, they will be pushed twice.
Only lines, in the server-config, with "route <network> <netmask>" are for the server itself.

And is my setup clean and secure?

Yes, this seems to me as a good setup.
As a small side-note, i would try to make the server run with both

user nobody
group nobody

as the server would still run as group-id "root"
And make sure the private key is only readable by the vpn-user and nobody else.

I've enabled on every side to side server MASQUARADING and sysctl.conf net.ipv4.ip_forward=1 .

Star Root Server hat 100MBits/100MBits and Clients have from 6/0,5 -> 100/5 Connection.

You could consider routing through the vpn-server instead of NAT all the traffic, but this all depends on the other systems connected to the servers and your network-setup.

niclas.mueller

Thank's for your replay!

So I've changed my configuration from ccd config to the Server.conf.

--> server.conf

port 1196

proto udp
dev tun
tun-mtu 1492
fragment 1300
mssfix
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh1024.pem
server 10.100.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt


push "route 10.0.0.0 255.255.0.0"
route 10.0.0.0 255.255.0.0

push "route 10.1.0.0 255.255.0.0"
route 10.1.0.0 255.255.0.0

push "route 10.2.0.0 255.255.0.0"
route 10.2.0.0 255.255.0.0

push "route 10.3.0.0 255.255.0.0"
route 10.3.0.0 255.255.0.0

push "route 10.4.0.0 255.255.0.0"
route 10.4.0.0 255.255.0.0

push "route 10.5.0.0 255.255.0.0"
route 10.5.0.0 255.255.0.0

push "route 192.168.178.0 255.255.255.0"
route 192.168.178.0 255.255.255.0

push "dhcp-option DNS 10.250.10.1"
push "dhcp-option DNS 10.0.10.1"
push "dhcp-option DOMAIN ms-dc.network"
push "dhcp-option WINS 10.250.10.1"
push "dhcp-option WINS 10.0.10.1"


keepalive 10 120

auth SHA1
cipher AES-256-CBC
comp-lzo

user nobody
persist-key
persist-tun
verb 3
client-config-dir ccd

and in ccd specific client config I only set if the Client uses for 0.0.0.0/0 the VPN Server or his default local network gateway.

I'll add the "group nobody" setting to my server.

But i didn't realized one thing.

As I wrote my first post, i decited that the sysctl.conf setting for IPv4 Package Routing was disabled :shock: .
As i created all configurations I've needed around 5 days for check and know how this system with routing work.

A friend says that only routing is needed for route packages from a client over a server with two subnets to the target. But i realized that this did not work, so I've created this masquarading.

I hove you understand what i meand.

Is there a optimazion for MTU Rate or compression ?

Thank's forward!

mwandelaar

niclas.mueller wroteA friend says that only routing is needed for route packages from a client over a server with two subnets to the target. But i realized that this did not work, so I've created this masquarading.

You only need ip-forwarding enabled when packets are leaving the vpn-server. When the packets remain inside the vpn-instance, you do not need the forwarding enabled.

On the other hand, when you are purely routing (so not NAT), the destination-systems all need to know where the other networks (from inside/behind the vpn-server!) are coming from and have routing-entries to know where the traffic needs to send back to.

I hove you understand what i meand.

Hopefully my answer helps.

Is there a optimazion for MTU Rate or compression ?

Compression can be set on or automatically. The LZO algoritm wil try to compress what's actually compressible. So you don't need optimalisations for that.

For the MTU-setting, my experience is that you only need tuned MTU-settings when networks in between the server and client is using different MTU-settings, like sometimes used on DSL-lines. Most of my vpn-networks work fine with "default" MTU-settings.