Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

ovpn+tinyproxy tiny:312x=>tun+ HELP!!!!!
New on LowEndTalk? Please Register and read our Community Rules.

ovpn+tinyproxy tiny:312x=>tun+ HELP!!!!!

lowendtalk rocks, that said:
I'm trying to make something I haven't found a guide for, so please don't ask me to google it, I've already googled it.

I have a [email protected] service implementation, which works for "systemctl start [email protected]" it has the "--proxy-noexec" argument so I can set my routing rules according to my network. all good so far.

when openvpn establishes the connection it will create a set of files for starting a tinyproxy service with the same @=>;, so tinyproxy knows what ip to bind to according to the one assigned by vpn server. so far so good.

I want to start a tinyproxy instance for each openvpn connection so using localhost:3128 will use tun0, 3129 will use tun1 and so on.

when I make several openvpn connections, tun0 and tun1 MIGHT get the same local ip assigned to them (ex:

So when I make a rule like

"ip rule add from checkout 100"

"ip route add default via dev tun0 table 100" #vpn gateway

MIGHT be routing requests through the wrong tun interface.

Marking packets in the PREROUTING phase isn't a solution, since I'm already using a specific port for each tinyproxy instance, the problem is with the NEW connection tinyproxy establishes for the remote peer (ex:

I've seen GUID or UID approaches which don't apply for this case, since all the tinyproxy instances use the same user.

Also I've seen the ip route suit not allowing the --pid anymore (which would be a fantastic solution to this).

the only solution I can think of to make it work for several "dynamic values" tinyproxy instances, is giving tinyproxy a new conf option named-like "fwmark" and marking the packets that go from TINYPROXY to the remote server (ex: so I can correctly forward them to the right tun interface..

After a couple try-and-error I am stuck with "spurious" packet retransmissions and I would like to call all the tremendous-minds here so maybe we can all figure a definitive in-code clean solution.

this involves touching tinyproxy c code and this is what I got so far:

SCREENSHOTS of packet captures:
case 1:
just apply a rule to all packets from tun+ local ip to go straight to that tun's default gateway.. (NOT 100% A SOLUTION since multiple TUN can have the same ip).

case 2:
applied a code change to tinyproxy source to add FWMARK=3 to the sockfd before it tries to connect.

PASTEBIN for code changes, unit files and scripts:

SO at this point I don't know why tinyproxy connect() attempt to is not getting the ipecho response, since it's freaking giving a response and it even shows up coming back to tun0, then the retransmits begin and I start swearing all around the place.

thank you all guys/girls/etc in advance, I really feel comfy coming here every day to leech offers and always enjoy the drama.


Sign In or Register to comment.