How to wrap traffic in an OpenVPN tunnel?

Question

linux

Hello. I got stuck with a seemingly simple task. You need to make an openVPN server and when connecting to it, wrap all traffic in a tunnel.
Server config:

port 443
proto tcp 
dev tun
cipher DES-EDE3-CBC
tls-auth ta.key 0 
ca ca.crt 
cert server.crt 
key server.key 
dh dh2048.pem 
server 10.8.0.0 255.255.255.0 
ifconfig-pool-persist ipp.txt 
keepalive 10 120 
comp-lzo 
persist-key 
persist-tun 
status openvpn-status.log 
log /var/log/openvpn.log 
verb 3

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

Customer:

client
dev tun
proto tcp
remote VPNIP 443
resolv-retry infinite
nobind
persist-key
persist-tun
cipher DES-EDE3-CBC
log /var/log/openvpn.log
ca /etc/openvpn/ca.crt
cert /etc/openvpn/cert.crt
key /etc/openvpn/key.key
ns-cert-type server
tls-auth /etc/openvpn/ta.key 1
comp-lzo
verb 3
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

The connection is working fine. However, access is lost. When connecting, only access to the VPN server is preserved due to the creation of a route to it when connecting.
Ubuntu 15.04 client
This is what the routing table looks like before the tunnel is up:

Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0         192.168.0.250   0.0.0.0         UG    100    0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

Like this after:

Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.0.250   0.0.0.0         UG    100    0        0 eth0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
46.101.159.196  192.168.0.250   255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 eth0

At the same time, on the tun0 interface of the server, I see traffic FROM the client.
The iptables rules are:

*filter
:INPUT DROP [29:2756]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1774:233423]
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
COMMIT
*nat
:PREROUTING ACCEPT [2097:132464]
:INPUT ACCEPT [320:18093]
:OUTPUT ACCEPT [646:47601]
:POSTROUTING ACCEPT [646:47601]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

Well, forwarding is enabled:

:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

What is wrong here?..

Answer 1

Suddenly, the problem is in the palm of your hand. Insufficient forwarding rules. This is how it works:
*filter
:INPUT DROP [6:303]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [744:429859]
-A INPUT -p tcp -m conntrack --ctstate NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp - -dport 80 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Wed Dec 23 15:04:17 2015
# Generated by iptables-save v1.4.21 on Wed Dec 23 15:04:17 2015
*nat
:PREROUTING ACCEPT [132:15943]
:INPUT ACCEPT [2:231]
:OUTPUT ACCEPT [26:1873]
:POSTROUTING ACCEPT [26 :1873]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Wed Dec 23 15:04:17 2015

Answer 2

Well, if packets come into the tunnel from the client to the server, then you need to deal with the firewall. Start a ping of something on the Internet from a client, and see which counters on the firewall change to understand what rules packets from the client pass through and which ones do not.