diff --git a/MA-Inhalt.tex b/MA-Inhalt.tex
index 84de333..d1e3033 100644
--- a/MA-Inhalt.tex
+++ b/MA-Inhalt.tex
@@ -516,13 +516,13 @@ Jeglicher weiterer Datenverkehr aus dem VPN-Netz heraus ist gestattet.
 
 \section{Konfiguration von OpenVPN}
 Nach der Einrichtung des Servers wird in diesem Schritt die Konfiguration des OpenVPN-Servers im Detail erläutert.
+Nähere Informationen zu den verwendeten Optionen können in \cite[][]{man:openvpn} nachgeschlagen werden.
 
 \paragraph{Erreichbarkeit des Dienstes}
 Laut Anforderung~\ref{req:dualstack} aus Abschnitt~\ref{sct:requirements} soll der VPN-Dienst über IPv4 und IPv6 aus dem Internet erreichbar sein.
 Als Ausgangspunkt dafür wird der DNS-Name des VPN-Dienst verwendet, der auf die IPv4- und IPv6-Dienstadresse zeigt.
 
-\textbf{Server}
-In der Serverkonfiguration reichen die ersten drei Zeilen aus, um über IPv4 und IPv6 auf UDP-Port~1194 den VPN-Dienst anzubieten:
+In der \textbf{Serverkonfiguration} reichen die ersten drei Zeilen aus, um über IPv4 und IPv6 auf UDP-Port~1194 den VPN-Dienst anzubieten:
 \begin{lstlisting}
 port 1194
 proto udp
@@ -532,8 +532,7 @@ multihome
 OpenVPN beantwortet damit Anfragen für alle auf dem Server konfigurierten IP-Adressen.
 Da auf dem Server neben den Dienstadressen auch die Maschinenadressen existieren, wird OpenVPN mit \texttt{multihome} angewiesen, eingehende Pakete mit der IP-Adresse zu beantworten, an die diese Pakete gerichtet waren.
 
-\textbf{Client}
-In der Clientkonfiguration wird OpenVPN mit \texttt{nobind} angewiesen, den Clientsocket nicht an eine lokale Adresse zu binden. Die Angaben \texttt{port} und \texttt{proto} legen fest, wie der VPN-Server zu erreichen ist.
+In der \textbf{Clientkonfiguration} wird OpenVPN mit \texttt{nobind} angewiesen, den Clientsocket nicht an eine lokale Adresse zu binden. Die Angaben \texttt{port} und \texttt{proto} legen fest, wie der VPN-Server zu erreichen ist.
 Über \texttt{remote} wird dann der zu verwendende VPN-Server explizit genannt.
 Die Erreichbarkeit über IPv4 und IPv6 ergibt sich aus den im DNS eingetragenen IP-Adressen.
 \begin{lstlisting}
@@ -547,7 +546,9 @@ Das UDP-Protokoll verwendet, weil das TCP-Protokoll in Kombination mit stark aus
 Bei Interesse kann eine detaillierte Analyse der Probleme der TCP-in-TCP-Situation in \cite[][]{analysis:tcpintcp} nachgelesen werden.
 
 \paragraph{IP-Adressen im VPN-Tunnel}
-Die vom IT-Team vergebenen IP-Adressbereiche für VPN-Clients werden durch den OpenVPN-Server an die Clients vergeben. In der Clientkonfiguration sind keine Anweisungen notwendig.
+Die vom IT-Team vergebenen IP-Adressbereiche für VPN-Clients werden durch den OpenVPN-Server an die Clients vergeben.
+In der Clientkonfiguration sind keine Anweisungen notwendig.
+Die \textbf{Serverkonfiguration} enthält diese Anweisungen:
 \begin{lstlisting}
 topology subnet
 server 10.2.0.0 255.255.0.0
@@ -556,9 +557,9 @@ server-ipv6 2001:638:614:1750::/64
 Mit \texttt{topology subnet} wird festgelegt, dass die IPv4-Adressvergabe so durchgeführt werden soll, als wären alle VPN-Clients mit dem VPN-Server in einem Subnetz.
 Anschließend werden mit \texttt{server} und \texttt{server-ipv6} die IP-Netze festgelegt, die an die VPN-Clients vergeben werden sollen.
 
-
 \paragraph{Erreichbare Netze im VPN}
-In der Serverkonfiguration werden \texttt{push}-Anweisungen eingetragen, über die IPv4- und IPv6-Routen an die VPN-Clients bekannt gegeben werden können.
+In der \textbf{Serverkonfiguration} werden \texttt{push}-Anweisungen eingetragen, über die IPv4- und IPv6-Routen an die VPN-Clients bekannt gegeben werden können.
+Ein VPN-Client ist durch die Anweisung \texttt{client} implizit auch mit dem Parameter \texttt{pull} konfiguriert, sodass die vom Server über \texttt{push} bekanntgegebenen Optionen übernommen werden.
 Zunächst werden alle IPv4-Routen bekanntgegeben:
 \begin{lstlisting}
 push "route 141.71.38.0 255.255.255.0 vpn_gateway"	# DMZ