No-Ip dynamic update client blocked by iptables

SomethingWitty · 05-02-2017, 04:26 PM

Dear all,

First of all I am completely new to the world of Linux, so please forgive me any mistakes (or plainly idiotic things).

So the project I am working on is starting a VPN. I am not sure if I will actually use it, but I thought it would be a nice project to start with to teach me something about linux and networking. I had to use the dynamic update client (DUC) from No-ip.com to be able to reach my system. However, the DUC did not update. When flushing my iptables temporarily the DUC did work. Therefor I am assuming it is a problem of my iptables blocking the DUC from reaching the server. I know port 80, 443 and 8245 should be forwared and thus it would be benificial if my iptables would not block these ports. Port 80 and 443 were already accepted, but port 8245 was still blocked. However, even after adding this port to my tables the DUC would still not function. So now I am at a loss. Since flushing my iptables fixed the problem I still think it has to do with my iptables. Currently they look like this.

Quote:

-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
-A OUTPUT -o lo -j ACCEPT

-A INPUT -p icmp -m state --state NEW --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT

-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 22 -j ACCEPT

-A INPUT -i eth0 -p udp -m state --state NEW,ESTABLISHED --dport 1194 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state ESTABLISHED --sport 1194 -j ACCEPT

-A INPUT -i eth0 -p udp -m state --state ESTABLISHED --sport 53 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED --dport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 80 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT

-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 8245 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 8245 -j ACCEPT

-A INPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 4
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 4
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_OUTPUT_denied: " --log-level 4

-A INPUT -j REJECT
-A FORWARD -j REJECT
-A OUTPUT -j REJECT

I admit this is largely based on what I read on the internet, but for my amateur eye it looked like a coherent set. But I am at a loss why the DUC is being blocked and hope you guys might have some advice for me.

Thanks for your help and time in advance,

Pearlseattle · 05-02-2017, 07:09 PM

Hi

I don't know much about FW, but still, here are my recommendations:

1)
Don't put everything inside a single monolithic bloc - split it up, as it's easier to handle.
E.g. the "main" script that you would call could look like this:

Code:

#!/bin/bash

#The bridge
export LAN=br0
#The network interface that connects to the outside world
export WAN=br0
#The internal NIC
export INT=lo
#Path where I saved all the files
MYPATH="/opt/myscripts/firewall"

#START

#Reset everything
iptables --flush
iptables --delete-chain

#Set up the default behaviours for when no rule explicitly blocks or allows something
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#Let everything to the loopback interface
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#Now a "ping localhost" should work

"$MYPATH"/iptables-start-1input.sh
"$MYPATH"/iptables-start-2output.sh
"$MYPATH"/iptables-start-3forward.sh
"$MYPATH"/iptables-start-4logging.sh

2)
Put at the very end the stuff that logs everything which you don't explicitly allow nor deny in the other scripts, which in this example would be the contents of "iptables-start-4logging.sh", which could look like this:

Code:

#!/bin/bash

#Max log label string length is "xxxxxxxxxxxxxxxxxxxxxxxxxxx"
iptables -A INPUT -j LOG --log-prefix "Def inbound rejection: "
iptables -A OUTPUT -j LOG --log-prefix "Def outbound rejection: "
iptables -A FORWARD -j LOG --log-prefix "Def forwarding rejection: "

This might seem at first unrelated to your question, but indirectly, by implementing a log for "anything unexpected" you'll always immediately be able to identify anything that blocks the traffic that you actually want to go through.

Btw. pls. keep in mind that as much as I know, "the future" of Linux firewall is "nftables" (using it since a while and it's not bad, but most of the software still has to catch up).

frankbell · 05-02-2017, 09:28 PM

Per the noip docs, have you opened ports 80, 443, and 8245?

SomethingWitty · 05-06-2017, 04:09 PM

Sorry for the late reply.

Quote:

Originally Posted by Pearlseattle

Hi

I don't know much about FW, but still, here are my recommendations:

1)
Don't put everything inside a single monolithic bloc - split it up, as it's easier to handle.
E.g. the "main" script that you would call could look like this:

Code:

#!/bin/bash

#The bridge
export LAN=br0
#The network interface that connects to the outside world
export WAN=br0
#The internal NIC
export INT=lo
#Path where I saved all the files
MYPATH="/opt/myscripts/firewall"

#START

#Reset everything
iptables --flush
iptables --delete-chain

#Set up the default behaviours for when no rule explicitly blocks or allows something
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#Let everything to the loopback interface
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#Now a "ping localhost" should work

"$MYPATH"/iptables-start-1input.sh
"$MYPATH"/iptables-start-2output.sh
"$MYPATH"/iptables-start-3forward.sh
"$MYPATH"/iptables-start-4logging.sh

2)
Put at the very end the stuff that logs everything which you don't explicitly allow nor deny in the other scripts, which in this example would be the contents of "iptables-start-4logging.sh", which could look like this:

Code:

#!/bin/bash

#Max log label string length is "xxxxxxxxxxxxxxxxxxxxxxxxxxx"
iptables -A INPUT -j LOG --log-prefix "Def inbound rejection: "
iptables -A OUTPUT -j LOG --log-prefix "Def outbound rejection: "
iptables -A FORWARD -j LOG --log-prefix "Def forwarding rejection: "

This might seem at first unrelated to your question, but indirectly, by implementing a log for "anything unexpected" you'll always immediately be able to identify anything that blocks the traffic that you actually want to go through.

Btw. pls. keep in mind that as much as I know, "the future" of Linux firewall is "nftables" (using it since a while and it's not bad, but most of the software still has to catch up).

Thank you for your reply. I did not know about nftables, I will look into it. Thanks for the advice. The rest of your suggestions I can hopefully implement soon. It has been a bit busy recently.

Quote:

Originally Posted by frankbell

Per the noip docs, have you opened ports 80, 443, and 8245?

Thanks for your reply. As per my basic knowledge I think those ports should be openend in iptables by their specific rules. If I am correct these rules should fix that, right?

Quote:

-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 80 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT

-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 8245 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 8245 -j ACCEPT

Regards

lazydog · 05-07-2017, 04:15 PM

Your firewall rules and how they need to be setup are going to depend on how your network is deployed now.

Is the VPN and the web site on the same system? If so then you are going to need INPUT rules for your tun0 interface. If the web site is on another computer then you are going to need FORWARD rules for your tun0 interface.

I am thinking that your VPN and the web site are on the same computer as you have stated if you remove the firewall it all works.

So I cleaned up your rules for you. I agree that you should group your rules together as it makes it easier to find what you are looking for.

Code:

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m conntrack --ctstate --icmp-type 8 -j ACCEPT
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW --dport 22 -j ACCEPT
-A INPUT -i eth0 -p udp -m conntrack --ctstate NEW --dport 1194 -j ACCEPT


# If your tun0 and web server are on the same system then you need the following rules
#
-A INPUT -i tun0 -p udp -m conntrack --ctstate NEW -m multiport --dport 80,443,8245 -j ACCEPT


-A INPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_INPUT_denied: " --log-level 4
-A INPUT -j REJECT


# These rules are not required as the first rule will allow all ESTABLISHED and RELATED connection through
#
#-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
#-A INPUT -i eth0 -p udp -m state --state NEW,ESTABLISHED --dport 1194 -j ACCEPT
#-A INPUT -i eth0 -p udp -m state --state ESTABLISHED --sport 53 -j ACCEPT
#-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 80 -j ACCEPT
#-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 443 -j ACCEPT
#-A INPUT -i tun0 -j ACCEPT
#-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED --sport 8245 -j ACCEPT


-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -o eth0 -p udp -m conntrack --ctstate NEW --dport 53 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m conntrack --ctstate NEW --dport 80 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m conntrack --ctstate NEW --dport 443 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m conntrack --ctstate NEW --dport 8245 -j ACCEPT
-A OUTPUT -o tun0 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_OUTPUT_denied: " --log-level 4
-A OUTPUT -j REJECT


# These rules are not required as the first rule will allow all ESTABLISHED and RELATED connection through
#
#-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 22 -j ACCEPT
#-A OUTPUT -o eth0 -p udp -m state --state ESTABLISHED --sport 1194 -j ACCEPT
#-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED --dport 53 -j ACCEPT
#-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 80 -j ACCEPT
#-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 443 -j ACCEPT
#-A OUTPUT -o tun0 -j ACCEPT
#-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 8245 -j ACCEPT


-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "iptables_FORWARD_denied: " --log-level 4
-A FORWARD -j REJECT

Normally I don't place anything in the OUTPUT chain as I normally trust everything leaving my system so the OUTPUT rule could be as simple as

Code:

-A OUTPUT -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

and the rest of the rules could be removed.

If in fact your web server and your VPN are on different machines then change

Code:

-A INPUT -i tun0 -p udp -m conntrack --ctstate NEW -m multiport --dport 80,443,8245 -j ACCEPT

to

Code:

-A FORWARD -i tun0 -p udp -m conntrack --ctstate NEW -m multiport --dport 80,443,8245 -j ACCEPT

As to nftables or firewealld, I do not see them taking over anytime soon even though big brother, RedHat, is pushing firewalld down their users throats.

While I have not looking into it I believe that nftables, like firewalld, is a front end for iptables. If you compare the output from firewalld you will see it uses iptables setup with the exception that firewalld creates many more tables then what is necessary making things more complicated.

SomethingWitty · 05-10-2017, 04:40 PM

Thanks lazydog for the help!

Indeed, both are indeed running from the same machine (raspberry pi by the way, in case this is relevant). The way you cleaned up the rules seems much better. Trusting your own output makes sense, now you mention it :-)
My apologies for not posting my own cleaned rules yet. I was quite busy lately and could not find the time to properly sit down and sort things out. I am not at the level yet to do it quickly and did not want to bother your time with a half finished product.
The guides I was following to learn something about iptables were appearently a bit out-dated, since they did not mention the conntrack or the ctstate functions. I am quite busy with work at the moment, but I will try to find some time this weekend to study conntrack, ctstate and to continue the work on the VPN.

Regards!

lazydog · 05-10-2017, 07:29 PM

Quote:

Originally Posted by SomethingWitty

Thanks lazydog for the help!

Glad I could help.

Quote:

My apologies for not posting my own cleaned rules yet. I was quite busy lately and could not find the time to properly sit down and sort things out. I am not at the level yet to do it quickly and did not want to bother your time with a half finished product.

No apologies necessary. Life will always find a way to get in the way.

Quote:

The guides I was following to learn something about iptables were appearently a bit out-dated, since they did not mention the conntrack or the ctstate functions. I am quite busy with work at the moment, but I will try to find some time this weekend to study conntrack, ctstate and to continue the work on the VPN.

Yeah, I don't think there is much out there in a way of an up-2-date tutorial. I learned a lot about building firewall following this IPTABLES TUTORIAL. It too is out of date but a lot of what is in there is still relevant and what is missing can be found in the man pages