0

I have 2 kinds of proxies in my local machine : stunnel and TOR-VPN.

  • stunnel is listening on port 6666
  • TOR-VPN is listening on port 9040

I want to get web traffic to go to stunnel first and the output traffic of stunnel go to tor-vpn. This needs double redirecting. is it possible to do it with iptables? I mean by using "table nat chain OUTPUT".

Because as far as I know "table nat chain OUTPUT" cant be called twice.

web traffic = browser listening on 127.0.0.1:6666

these are my rules:

iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-ports 6666

iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp -j REDIRECT --to-ports 9040

iptables -t nat -A OUTPUT -p udp -m owner --uid-owner bob -m udp --dport 53 -j REDIRECT --to-ports 53

iptables -t filter -A OUTPUT -p tcp --dport 6666 -j ACCEPT

iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp --dport 9040 -j ACCEPT

iptables -t filter -A OUTPUT -p udp -m owner --uid-owner bob -m udp --dport 53 -j ACCEPT

iptables -t filter -A OUTPUT -m owner --uid-owner bob -j DROP

the above rules make stunnel work independently from TOR/VPN. i mean when browser is set with proxy, no traffic will go through TOR/VPN but if i turn off the proxy in browser, all traffic will go through TOR/VPN.

now i want to let browser have the proxy on and all web traffic go to stunnel first, but outgoing stunnel traffic(outgoing loopback traffic) redirects to TOR/VPN(127.0.0.1:9040)

is it possible ? how can i do that? somehow i mean double redirecting inside system.

Policy of all tables is ACCEPT

jww
  • 97,681
  • 90
  • 411
  • 885
amin.2014
  • 11
  • 2
  • 6
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. – jww Jun 14 '18 at 01:04

2 Answers2

0

Checking that this is what you mean :

You have stunnel bound to port 6666 (localhost:6666) and you have tor bound to 9040 (localhost:9040). You want it so your web traffic will go THROUGH stunnel (so destination is localhost:6666) but the OUTBOUND traffic FROM stunnel (with inbound traffic originally from your client redirected to stunnel) should be DESTINED to tor (localhost:9040) ? Is this correct ?

If so, and I am thinking clearly enough (it is just 7:00 and I've been awake far too many hours for a difficult night), this is indeed possible (the reverse is, too). You need to masquerade the destination address (and indeed port) based on the source (address and port (you don't have to specify both, I might add)). Something like this:

iptables -t nat -I PREROUTING -p tcp --sport 6666 -j DNAT --to-destination 9040

If this is not what you mean (or alternatively I made a typo, am not clear headed or being an idiot in some way (in all cases showing myself to be a user as everyone is!), if any it is probably the latter) then please respond. I'll see about enabling email notification so that I see the response. If I don't, however, I apologise in advance.

As an aside: unless you have a final rule in each CHAIN (not table, just as an fyi: a table is filter, nat (which I specify in the above and indeed it is necessary), etc. and CHAIN is INPUT, OUTPUT, FORWARD and others created by the option -N) you shouldn't have -P ACCEPT ('that which is not explicitly permitted is forbidden' and similar wording - i.e. have DROP). The exception is perhaps OUTPUT (but depends on what you need, in the end). However, when dealing with interface 'lo' you'll want to ACCEPT all traffic always, in any case (i.e. specify -i lo and -o lo, depending on chain, and jump to ACCEPT). Of course, maybe you're behind another device but still best practise to not accept anything and everything! (I should also state that you have different chains per table so yes you can specify different tables but the policy is for the chain IN that table)

Edit: something else: no, you don't have to deal with SNAT when you want DNAT and the reverse is true. Anything to the contrary is a misunderstanding. The reason is you're masquerading the CONNECTION. As the man page shows:

It specifies that the destination address of the packet should be modified (and all future packets in this connection will also be mangled), and rules should cease being examined.

Edit: If I understand you (now) you actually have two interfaces involved. Or more specifically you need the following:

You have a service you want encrypted. This is tor. Now, you're using stunnel to do this. To this end you want stunnel to forward traffic to tor. Is this right? If yes, then know that stunnel has the following directives (I actually use similar for something else). Here's a mock setup of a service. [tor] accept = 6666 connect = 9040

In addition, just as a note: connect can also be a remote address (remote address implies an external address (with port) or even a certain interface (by IP and also with port) on the system (I use external in the sense of you specify ip and port rather than just a port). Furthermore, accept can specify address (with same rules: ip before the port (except that it is obviously on the local machine so no external IP)). You could explain it, perhaps, as stunnel is where the service would bind to except that the service is stunnel and the service it is encrypting is elsewhere (shortly: the bind(2) call allows specific IP or all IPs on the system, and you're basically configuring stunnel to do this).

(And yes, you're right: the sport should have been dport.)

IF this is not what you need then I do not understand all variables. In that case, if you can elaborate on which interfaces (this includes ports and which service per interface) are involved as well as clients involved (and where they send). Because it is a lot more helpful if others know EXACTLY what you need than infer certain parts. Makes it much easier to solve a problem if you know what the problem is entirely. Maybe I've been dense and I should put together it all (and I admit sleep problems - which I have for a long, long time - does not help that, but...) I haven't, I think.

  • first of all, i should thank you for your comment. you completely understood my question, and i tested the rule you gave me, but still there is no success. "PREROUTING" is the chain for incoming packets to my system (it means, this chain is called when the source ip of the packet is not my ip address) and i dont think this chain can help solve my problem. what is your idea? thanks in advance. – amin.2014 Jan 17 '15 at 23:58
  • Sorry on the delay - only found out you responded because SO emailed it to me. See my revised answer. I mixed two things in my head and I threw you off in the wrong direction (I seem to remember I was only half-awake too but I wouldn't at all suggest that is where I went wrong). If this doesn't help I'll look in to it - I could set up services for this very purpose (if I have to) and then I'm 100% sure I could solve it. –  Jan 20 '15 at 13:16
  • really thanks for the comment. first, you should know that the rule u gave must be changed to this : iptables -t nat -I PREROUTING -p tcp -d "ip of stunnel server" -j REDIRECT --to-port 9040. because packets go to stunnel program and their destination ip will change to stunnel server ip and this ip is helpful for writing the rule but port 6666 has no use. second there is actually no big difference between the 2 rules u wrote. last time i changed your rule (-j DNAT --to-destination 9040) to (-j DNAT --to-destination 127.0.0.1:9040). – amin.2014 Jan 20 '15 at 22:19
  • third is that i think what u say about PREROUTING chain is wrong. check out this link: http://www.faqs.org/docs/iptables/traversingoftables.html i need to understand chain traversal when loopback interface comes to play. i can't find any article explaining chains order when using loopback interface. – amin.2014 Jan 20 '15 at 22:24
  • Yes. I thought it odd too. However, I also saw something in the man page that made me think, well, okay 'it could be that'. It occurred to me later that I can actually test this easily. I'll do that momentarily and get back to you. And something else you reminded me of there is of use. Will respond when I can. –  Jan 21 '15 at 13:24
  • I think I might have misunderstood you and I also just realised something that might also help. You're saying you want to encrypt web traffic by having it forward to 9040? That is the destination port is 6666 (that you send initial packet to) but it actually forwards traffic to 9040? If so you might not even need iptables. Editing answer to explain this (and will remove some irrelevant things). –  Jan 21 '15 at 13:35
  • part of your latest answer (accept = 6666 connect = 9040) can be helpful. i did not test it for this end, but i set up some other services using this method before. anyway i myself found the answer and thank you for your answer because after 2 months u made me think again on this problem and find the answer i thought it cant be solved. – amin.2014 Jan 27 '15 at 03:20
  • by the way what u said earlier about prerouting chain is relatively right. loopback interface is an independent interface ( like some other eth interface.for example in a situation that we have more than 1 eth intefaces) and all chains like prerouting and input chains are called for it. but prerouting does not have any use in my problem. – amin.2014 Jan 27 '15 at 05:13
  • I honestly don't recall what I even suggested with prerouting and lo specifically. In any case, indeed it is independent (and is the interface that expects all traffic to be allowed - and not doing so can cause problems). To be truthful I don't even recall much of the entire discussion (if any) so I can't really remark on what I might have claimed (or whatever). Glad you sorted it out, however. I rather guess I didn't follow your problem completely. It doesn't really matter though - the only thing that matters is you solved it. –  Jan 27 '15 at 23:24
-1

I found the answer by myself. in my first post, i said something that was completely wrong and because of that, i could not do double redirecting. i said:

Because as far as I know "table nat chain OUTPUT" cant be called twice

it is wrong and "table nat chain OUTPUT" can be called twice. i dont know what exactly i did 2 months ago that thought "table nat chain OUTPUT" cant be called twice.

this is the tables and chains order when using some services on loopback interface or not:

Without having any services on loopback:

Generated packets on local machine -> nat(OUTPUT) -> filter(OUTPUT) -> wlan(ethernet) interface

With having some services on loopback:

Generated packets on local machine -> nat(OUTPUT) -> filter(OUTPUT) -> loopback interface -> nat(OUTPUT) -> filter(OUTPUT) -> wlan(ethernet) interface

these are my rules to solve the problem:

iptables -t nat -A OUTPUT -p tcp -m tcp --dport 6666 -j REDIRECT --to-ports 6666
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp -j REDIRECT --to-ports 9040
iptables -t nat -A OUTPUT -p udp -m owner --uid-owner bob -m udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A OUTPUT -d "StunnelServerIp" -o wlan0 -p tcp -j REDIRECT --to-ports 9040
iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp --dport 9040 -j ACCEPT
iptables -t filter -A OUTPUT -p udp -m owner --uid-owner bob -m udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp -m tcp --dport 6666 -j ACCEPT
iptables -t filter -A OUTPUT -m owner --uid-owner bob -j DROP
amin.2014
  • 11
  • 2
  • 6