HTTPTunnel OpenVPN server to client traffic broken

[dbdoshi]

I have my LAN setup as 10.76.5.0/24. The router is 10.76.5.1 (ASUS). My OpenVPN server is running on 10.76.5.16 (Windows 10 desktop), lets call the IP as "OS". I have another laptop (Windows 10) with IP of 10.76.5.17 (call it "OC") which is my OpenVPN client box.

I am running HTTPTunnel Client on OC on port A. This forwards all traffic to OS, which is running the HTTPTunnel Server. The HTTPTunnel encapsulates all TCP traffic in HTTP GET/POST methods. The HTTPTunnel server listens on port 80 on OS. The OpenVPN client connects to "127.0.0.1:A". This traffic is forwarded to OS over port 80. The HTTPTunnel server then forwards this traffic to the OpenVPN server running on OS.

Basically, I have:

OpenVPN Client --> HTTPTunnel Client --> HTTPTunnel Server --> OpenVPN Server.

(Here OpenVPN & HTTPTunnel Clients are on OC, while OpenVPN & HTTPTunnel Servers are on OS).
(And, HTTPTunnel client to HTTPTunnel server is over LAN (or will be over WAN eventually)

I can make the connection fine. The problem is the return data, because the HTTPTunnel runs in transparent mode. So, even though the HTTPTunnel server acts as "OpenVPN client" to the OpenVPN server, the client source IP that the OpenVPN server sees is actually the LAN IP of 10.76.5.17 and not 127.0.0.1. My guess is that when OpenVPN server returns traffic back to the OpenVPN client, it sends it to the actual LAN IP and not 127.0.0.1. This breaks the return path from the OpenVPN server back to the client because no data is coming back to the HTTPTunnel server process. This means no data goes to the HTTPTunnel client and so, the OpenVPN client never receives any return traffic. Am I seeing this problem correctly?

How do I tell the OpenVPN server to return traffic to localhost (and to the same port used by HTTPTunnel server to connect to the OpenVPN server) irrespective of the client IP it sees for its incoming connection? Some thoughts:

1. I don't think I want to change the default route on OpenVPN server Windows route table to "127.0.0.1". I don't think that will work because then all traffic from this box will go to localhost... Basically this box will lose all connectivity to local LAN and to the router (and so no WAN) ...

2. I have to tell OpenVPN server to ignore the Windows routes when returning traffic back to the OpenVPN client (ignore the Source IP of the OpenVPN client) This return traffic should not leave the box to be routed, but should be forwarded to localhost instead. But, on the other hand, I have to tell the OpenVPN server to use the Windows routes when it is not "talking" to the OpenVPN client.

3. One thing I am really confused about though. In this particular situation of both OpenVPN server & client on the same subnet, why is the OpenVPN client not receiving any return traffic, even if this traffic is not coming via the HTTPTunnel? Is this a port issue? If say, HTTPTunnel server uses ephemeral port A to connect to the OpenVPN server (So, OpenVPN server sees this Port A as its client source port). But this Port A is not the actual port used by the actual OpenVPN client (say, ephemeral Port B) when it connects to the HTTPTunnel client,. So, even though the incoming traffic to the OpenVPN client box (via local subnet) successfully reaches the box itself, but actually going to Port A and not Port B?

But, say if Port A and Port B are same, will the OpenVPN client process get this return traffic? Basically, will this return traffic that is coming on LAN interface as opposed to the TUN interface (which is actually the interface that the OpenVPN client expects return traffic normally) be visible and accessible to the OpenVPN client process? Do OpenVPN clients listen on all interfaces on the box and with the same port numbers by default? I am guessing this has something to do with IP forwarding feature in the host operating system...

[TinCanTech]

I don't know how HTTPTunnel works , please try : http://http-tunnel.sourceforge.net/

One thing you could try is running the HTTPTunnel server and OpenVPN server on different machines.