I got an Openvpn server on Linux and use it to route all ipv4 traffic from my clients (win7,android, pfsense etc). I finally want to really understand the routing thing, although it works, but more because my server .conf was made upon trial and error :)
What i dont get, is which combination of options really is needed - what do those push things do other than the option "redirect-gateway def1" (which is explained on the openvpn man)? is it true, that i cant ommit redirect-gateway def1 because otherwise the traffic of the tunnel would be routed through the tunnel..?
What is currently working is the following set of route options on the server.conf (besides the other optiones, like tun device, client etc):
server 10.10.0.0 255.255.255.0 #ok, i assume thats needed for the client to find out which ip to get
push "redirect-gateway def1" # i get it, but it dont work on android or mac - there i have to set a program option "route all gateway through the vpn" for the tunnel to act as default-route
push "dhcp-option DNS 188.8.131.52" # as dnsmasq doesnt work i assume i need this for all dns beeing made through another (google) server
push "route 10.10.0.1"# is this helpful? it doesnt seem wo brake things, but shouldnt this be executed by redirect-gateway def1 already? for the time beeing, on my win7 client if i omit this it also works. but with or without this option i dont have a default-ipv4-gateway entry on the tap device in win7, although traffic is routed through the tunnel..
another thing i dont get is the dhcp is set to 10.10.0.5 if the clients get the ip 10.10.0.6. but theres notghin on 10.10.0.5, where does this come from?
oh man, plz help me understanding this, my routing knowledge is little to no... thx!
p.s. when i finally got this, i want to adress the constant "Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #961 ] " errors i get, already tried fragment 1300 mssfix but doesnt seem to help, although netalyzr said my mtu is 1376 and before that options it said that i cant send or receive fragmented packets. i suspect my provider masses with the udp packets..
edit: here is my server.conf
port 123 client-to-client proto udp dev tun0 ca *.crt cert *.crt key *.key dh *.pem server 10.10.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt duplicate-cn keepalive 10 120 push "redirect-gateway def1" push "dhcp-option DNS 184.108.40.206" push "dhcp-option gateway 10.10.0.1" max-clients 5 client-to-client fragment 1300 mssfix
edit: route commands now clear, thanks, oversaw the "server" part in the openvpn man.
now i have the following issues:
in an attempt to debug the connection (udp connection always gets packet replay) I built a tcp tunnel (based on the above config, just switched to tap0 on the server) and as soon as a download from the openvpn client starts i get the following log output:
"MULTI: packet dropped due to output saturation (multi_process_incoming_tun)"
so i added:
that led to less of the message, so i increased to
this leads to a connection drop. first it outputs some of these:
MBUF: mbuf packet dropped
write TCPv4_SERVER: Broken pipe (code=32)
Connection reset, restarting 
so i appended
bcast-buffers = 4096
which results in no more messages, but the speed still is dismal. also i dont know wether thats just a fix for some minor downloads and if it works stable with ongoing downloads or if the buffer fills up and it reconnects, so might be more broken than fixed..
whe using the udp tunnel i get nearly twice download speed and repeatedly this log message:
Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #650 ]
for example, while doing an oakla speedtest run, i get around 3 replay warnings during the download test and 5-6 during the upload test.
What can I do further improve the tunnel? thx!
edit: changed the title, so it matches the problem more.
edit: now using a 1 GB file from my openvpn server to test download speed instead of oakla and i have 16mbit over tcp, no error so far edit: ok, its not routed through the tunnel, it downloads directly - i assume thats because of the direct route to the openvpn server that is needed for the openvpn client.