Internet traffic not fully routed

Bagger

Hello,
I guess I have a clientside problem:
If I connect to my OpenVPN server via Android device, a tracert results that the traffic is going trough the tunnel.
But if i connect to the same OpenVPN server over a Windows10 PC just the traffic of my Firefox is routed over the tunnel but no tracert, RDP etc. pp.. Tracert to the public server-IP goes the way without tunnel, direct to the internal VPN-IP of the server (gw-IP) trough the tunnel. I realized this when i connected over RDP to a PC in the server's network (over the public DDNS), so i tried something and turned eg. IPv6 (client) off. My server has just Teredo IPv6 (hostable IPv4), my client and my Android device DS-Lite (hostable IPv6).
Server's LAN: gw192.168.5.1/24
Client's LAN: gw192.168.2.1/24
Server's LAN: net30->ccd gw10.1.2.1
push "redirect-gateway def1 bypass-dhcp" is set
I guess that i must set a specified route into my Windows10 PC that says "All traffic - exempt 192.168.2.1-192.168.2.255 - has to go over gw10.1.2.1" but i don't know how. I can tell you a lot about Wake on Lan but I never concern myself with routes and subnetmasks. It must be a small detail in the "clonkwork".
Can you help me?
Tell me, if you need configs etc.

PS: i saw, that "Gateway" in the Details of the TAP-plug (client-Win10) is empty, but Firefox goes over the tunnel and it works on other devices.

TinCanTech

Bagger wroteFirefox is routed over the tunnel but no tracert, RDP etc. pp.. Tracert to the public server-IP goes the way without tunnel

When you use --redirect-gateway to force data over the VPN, the one IP address which is not routed over the VPN is the public IP of your VPN server, otherwise the VPN packets would be routed through the tunnel and your VPN would collapse.

Bagger

FAIL! *headbang*
"tracert google.de" works
If I did tracert to my public IP from the LAN of this public IP (DDNS-adress), it was "client ->192.168.5.1 -> 192.168.3.1 (modem-IP)" so I believed, that it runs "client -> 10.1.2.1 -> 192.168.5.1 -> 192.168.3.1 (modem-IP) -> 192.168.5.1 -> NAT based port forwarding"
There is no way to connect so like descripted? I mean, theoretically would be possible...