Hello,
the VPN tunnel from 33.3 to the external VPN server works - the 10.1.0.0 is from both sites of the tunnel reachable.
Which routes and NAT rules must I set on R1 and R2 that 10.1.0.6/10.1.0.1 are reachable from the 34.0 network through the 33.1 and 33.30?
Thanks, very much.
Couple of things…
Is R1 acting as a NAT for the x.x.34.0/24 network; or is it just a router that routes the traffic?
How is routing between R1 and R2 handled currently? Can devices in x.x.33.0/24 “talk” directly with devices in x.x.34.0/24 without the use of a NAT?
In my opinion, the easiest thing would be to setup OSPF on R1 and R2 and have R2 advertise the network/IPs of the tunnel and beyond to R1. That is without knowing further details in how your network is setup. You can also use static routes.
Yes, 33.0 and 34.0 are NAT routed to the gateway (33.1) but 33.0 also routed directly to 34.0 without NAT (34.0 can directly communicate with 33.0).
Or can I solve it with port forwarding, that 33.1:1080 will be routed to 33.3:1080 and this will be routed through the tunnel to 10.1.0.1:1080?
I would need the tunnel only for socks proxy uplink.
Say what?
So the gateway on R1 is the NAT for both networks? Where is your ISP connection?
If x.x.33.0/24 and x.x.34.0/24 can “talk” directly with each other without using a NAT, simply configure routing - whether it be static or dynamic.
You’re trying to make this way more complicated than it needs to be. Also, without knowing how your network is configured, you could make things worse.
ISP is on 11.0 on another port of R1.
Ok, I will try it with static routes.
UPDATE_1: On R1 I set following route: 10.1.0.0/29 via 192.168.33.3 (now from 34.0 10.1.0.6 is reachable).
But from 34.0 I cannot ping 10.1.0.1 (only 10.1.0.6 is reachable).
UPDATE_2: Ok, now it runs, I forgot the two forwarding rules on R2. 
Thanks. 
Everything works fine but I get a lot of TCP Resets on the 33.3 router. The tunnel and bandwidth are stable. On the OpenVPN server there are no suspicious entries.
15:05:04 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61832, len 40
15:05:06 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61855, len 40
15:05:06 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61855, len 40
15:08:28 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61931, len 40
15:08:28 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61931, len 40
15:08:29 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61850, len 40
15:08:29 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:61850, len 40
16:11:52 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:55070, len 40
16:11:52 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:55070, len 40
Sometimes I also get some SYN,ACK entries.
16:54:34 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:60734, len 40
16:54:34 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:60734, len 40
16:54:34 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (RST), 10.1.0.1:8080->10.1.0.6:60734, len 40
17:06:02 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (SYN,ACK), 10.1.0.1:8080->10.1.0.6:63361, len 52
17:06:10 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (SYN,ACK), 10.1.0.1:8080->10.1.0.6:63361, len 52
17:06:26 firewall,info LAST DROP - INPUT input: in:OpenVPN out:(none), proto TCP (SYN,ACK), 10.1.0.1:8080->10.1.0.6:63361, len 52
The server (10.1.0.1) sends TCP resets to the client (10.1.0.6).
What could be the cause of this behavior?
Could this come from packets they come too late?
Maybe some packets needed too long and new one were requested and they reached before?
Websites will be loaded fully and without problems.
noone any idea? 
push
TCP-RST are typically sent when either no server process is running on that port (8080 in your case) or some access control (iptables/firewall) actively rejects the connections for some reasons.
It also happens when the TCP state machine runs into a timeout while expecting another packet from the requesting client that did not come. This is normal behaviour to signal the requesting party that the connection will be terminated compulsorily and it should free all related resources (buffers, sockets, etc.)
Hope this helps.