Bypassing VPN while using a kill switch - DD-WRT - iptables

I have setup OpenVPN on my R7800 router to connect to my VPN provider.
I want to bypass the tunnel for some sites.
For the sake of question let it be www.whatsmyip.com
I have two ip rules acting as kill switch for my VPN connection added to "Firewall" script:
iptables -I FORWARD -o $WAN_IF -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -o $WAN_IF -p tcp -m state --state NEW -j REJECT --reject-with tcp-reset
Actually a bit more complicated since I use Policy Based Routing (PBR), but it shouldn't matter. Reference
I have found that bypassing the tunnel for specific domain names is possible using the following commands:
allow-pull-fqdn
route www.whatsmyip.com 255.255.255.255 net_gateway
Reference
I have entered the above to "OpenVPN Client --> Additional Config" field.
The above seems to work, since the kill switch kicks in and forbids the connection and page is not loading.
So, I need to add a firewall rule to allow this connection.
The following rule is entered below the kill switch rules:
iptables -I OUTPUT -d whatsmyip.org -j ACCEPT
I came up to this reading this
Apparently, the rule I came up is not right.
How can I properly modify the above rule in order to bypass the kill switch successfully?
Thank you in advance.

I am posting the answer here for clarity.
iptables -I FORWARD -d whatsmyip.org -o $(get_wanface) -j ACCEPT
No need for allow-pull-fqdn, it is default in OpenVPN 2.4

Related

iptables FORWARD rule blocking return traffic

I have a VM running OpenVPN with client-to-client disabled and I need some specific forwarding rules. IP forwarding on the VM is turned on.
The OpenVPN base network is 172.30.0.0/16 and that is further subdivided into /24 subnets with their own rules.
172.30.0.0/24 should have access to all the clients. The rest should not. I have 2 subnets defined at the moment; 172.30.0.0/24 and 172.30.10.0/24.
Following the suggestion at the bottom here;
https://openvpn.net/community-resources/configuring-client-specific-rules-and-access-policies/ - I set up my rules as follows;
iptables -A FORWARD -i tun1 -s 172.30.0.0/24 -j ACCEPT
iptables -P FORWARD DROP
This does not work. If I add a -j LOG at the top, I can see that traffic from my client at 172.30.0.1 connects fine to the client at 172.30.10.3, but all traffic it sends BACK is blocked.
If I set the policy to ACCEPT everything works and I can connect to the client just fine, so this is not a routing problem.
How can I set this up? And why doesn't the suggestion in that OpenVPN guide work?
I solved this by adding
iptables -A FORWARD -i tun1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
which allows established connections to return. Everything works as desired now.

Iptables masquerade not working on Debian VM

I have a VM in VirtualBox with Debian 10 and I'm trying to NAT masquerade it's output interface (enp0s8) so that it's clients (VMs connected to it) can access the Internet.
All interfaces in the system have an IP. I've already enabled forwarding with:
echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl -w net.ipv4.ip_forward=1
And then I executed:
iptables -t nat -A POSTROUTING -o enp0s8 -j MASQUERADE
However, whenever I execute the above, the following happens:
And no matter how many times I iptables --flush -t nat and repeat the process, the result is always the same. The rule I want to apply is never saved properly and the client's IPs are never masked.
What is the issue here? Almost all tutorials say this is the correct way for masquerading.
I've also tried using nftables, without success.
It is already showing the right output. To show the rules with the interface details, you need to use,
iptables -t nat -L -n -v
And btw, if you have setup NAT networking, it is already taken care to connect outside.
And have you set the default gateway of your clients to this box?

What iptables rules should I use in order for my Discourse app to be able to use Mandrill?

I am currently trying to secure a little my server before its release to the world. For now, there is just a Discourse instance running, that uses Mandrill as email smtp server.
There is an nginx server in front of that Discourse.
With no iptables rules, everything works fine. When I apply my rules, it brokes. I am still able to reach the Discourse and even send posts and everything, expect sending email.
With ./launcher mailtest app, it works. The Discourse error, however, is the following : ERREUR - getaddrinfo: Name or service not known.
I really try to find out myself what I should use. But I couldn't.
First, I was thinking a simple iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT was enough, but I was proved the contrary.
Some other inputs :
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
I set Discourse to use port 587 of Mandrill.
Okay, so I just released... This is not the right SE forum for that question. I'm sorry for that.
However, since I finally found a solution (it's always when you post your question that the question hits you in the face), let me share it.
I was missing a FORWARD rule between docker0 and eth0.
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o docker0 -j ACCEPT
Sorry for the inconvenient.

Redirecting from outgoing loopback traffic - is it possible?

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
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.
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

Setting up iptables for a hostapd wifi login page

I need some custom iptables for a login page of my wifi hotspot on my raspberry pi. I want an http login page: this is how it should work, I just don't know how to configure the iptables.:
Any connections on an ip address that is not already logged in, should be redirected to the pi's port 8181 (the server for my login page).
Any connections on an ip address that is logged in should be allowed to access the outside internet.
Any connections initially requesting the pi's port 8181 should be allowed.
How should I set this up with iptables?
Thanks!
I've found the following article very helpful when learning iptables:
http://wiki.centos.org/HowTos/Network/IPTables
Basically you can start with a something similar to:
# iptables -P INPUT ACCEPT
# iptables -F
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT
This will block pretty much everything other than SSH, outgoing connections, and connections that are previously established (ie from previous outgoing connections)
Once that is in place you need to do the redirection:
http://proghowto.com/iptables-redirect-port-80-to-port-8080
And finally you need to run something like the following for each ip that gets authenticated:
# iptables -A INPUT -s 192.168.0.4 -j ACCEPT