OpenVPN Tunnel between two LANs, traffic dropped on the way

I'd like to create a OpenVPN Tunnel between to LANs 192.168.1.0/24 and 192.168.2.0/24.
However somehow packets entering the tunnel on one side don't come out of the other side …

The following hosts are involved:

R1=192.168.1.1  Router in LAN 1
R2=192.168.2.1  Router in LAN 2
S1=192.168.1.10 OpenVPN Server in LAN 1, no ip tables, net.ipv4.ip_forward=1
C2=192.168.2.10 OpenVPN Client in LAN 2, no ip tables, net.ipv4.ip_forward=1
H1=192.168.1.20 Some host in LAN 1 with default gateway R1
H2=192.168.2.20 Some host in LAN 2 with default gateway R2

I set up OpenVPN and installed routes into the routers, configuration see below. Connection working, let's to some pinging.

C2> ping 10.8.0.1        # OK
C2> ping S1=192.168.1.10 # OK
C2> ping R1=192.168.1.1  # OK
S1> ping 10.8.0.6        # OK
S1> ping C2=192.168.2.10 # NO
H1> ping C2=192.168.2.10 # NO
H2> ping S1=192.168.1.10 # NO

I checked on S1 and C2 with tcpdump and I noticed that all ICMP requests arrive one end of the tunnel but don't come out the other end,
e.g. pinging at first S1 from H2, which did not work, then pinging C2 from S1

C2> tcpdump -s0 -i tun0
17:05:53.070047 IP C2 > 10.8.0.1: ICMP echo request, id 10190, seq 1, length 64
17:05:53.099990 IP 10.8.0.1 > C2: ICMP echo reply, id 10190, seq 1, length 64
17:06:04.115396 IP C2 > S1: ICMP echo request, id 10194, seq 1, length 64
17:06:04.148898 IP S1 > C2: ICMP echo reply, id 10194, seq 1, length 64
17:06:16.160644 IP 10.8.0.1 > C2: ICMP echo request, id 4479, seq 1, length 64
17:06:16.160720 IP C2 > 10.8.0.1: ICMP echo reply, id 4479, seq 1, length 64
17:06:11.532787 IP C2 > R1: ICMP echo request, id 10221, seq 1, length 64
17:06:11.563275 IP R1 > C2: ICMP echo reply, id 10221, seq 1, length 64
17:07:05.149219 IP H2 > S1: ICMP echo request, id 57470, seq 0, length 64

S1> tcpdump -s0 -i tun0
17:05:53.083547 IP 10.8.0.6 > S1: ICMP echo request, id 10190, seq 1, length 64
17:05:53.083624 IP S1 > 10.8.0.6: ICMP echo reply, id 10190, seq 1, length 64
17:06:04.130861 IP 10.8.0.6 > S1: ICMP echo request, id 10194, seq 1, length 64    
17:06:04.130941 IP S1 > 10.8.0.6: ICMP echo reply, id 10194, seq 1, length 64
17:06:11.546125 IP 10.8.0.6 > R1: ICMP echo request, id 10221, seq 1, length 64
17:06:11.546766 IP R1 > 10.8.0.6: ICMP echo reply, id 10221, seq 1, length 64
17:06:16.144123 IP S1 > 10.8.0.6: ICMP echo request, id 4479, seq 1, length 64
17:06:16.172989 IP 10.8.0.6 > S1: ICMP echo reply, id 4479, seq 1, length 64
17:06:43.928054 IP S1 > C2: ICMP echo request, id 4484, seq 1, length 64
17:06:54.095618 IP H1 > C2: ICMP echo request, id 1091, seq 1, length 64

So it does not seem to be a routing problem, nor any firewall related problem as iptables are empty on both S1 and C2.
Any idea what could be the problem? Why don't the packets arrive the end of the tunnel?
There seems to be some packet filtering enabled in OpenVPN.

R1 routes:

192.168.2.0/24 via 192.168.1.10 dev lan
10.8.0.0/24 via 192.168.1.10 dev lan

R2 routes:

192.168.1.0/24 via 192.168.2.10 dev lan
10.8.0.0/24 via 192.168.2.10 dev lan

S1 routes:

default via 192.168.1.1 dev eth0  proto static  metric 1024 
10.8.0.0/24 via 10.8.0.2 dev tun0  proto static  metric 20 
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.10 
192.168.1.1 dev eth0  proto dhcp  scope link  src 192.168.1.10  metric 1024 
192.168.2.0/24 via 10.8.0.2 dev tun0  proto static  metric 20 

C2 routes:

default via 192.168.2.1 dev wlp2s0  proto static  metric 1024 
10.8.0.1 via 10.8.0.5 dev tun0  proto static  metric 20 
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6 
192.168.1.0/24 via 10.8.0.5 dev tun0  proto static  metric 20 
192.168.2.0/24 dev wlp2s0  proto kernel  scope link  src 192.168.2.10

server.conf

dev tun
port 1195
proto tcp
server 10.8.0.0 255.255.255.0
route 192.168.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

ca       ca.crt
cert     server.crt
key      server.key
dh       dh2048.pem
tls-auth ta.key 0

comp-lzo
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody

client.conf

client
dev tun
port 1195
proto tcp-client
tls-client
remote mylan.de 1195

ca       ca.crt
cert     client.crt
key      client.key
tls-auth ta.key 1
verify-x509-name server name

comp-lzo
keepalive 10 60
persist-key
persist-tun
user nobody
group nobody