[SOLVED] iptables

ziphem · 07-31-2013, 11:48 PM

Hi, I was hoping I could get some feedback on improving my iptables for CentOS. I've struggled to get it this far, and I'm having one particular problem (dropping all forwards with one exception). In any case, I thought I would post it here in the hopes of getting some feedback, both in terms of the final product but also the journey of learning it.

The below is in a file, firewall.sh. Thanks a ton for any improvements, suggestions, or comments!

Code:

#!/bin/bash
#
#
# Flush all current rules from iptables and so start fresh
iptables -F
#
#
# Allow SSH connections on tcp port 123 and udp port 1194 (VPN)
iptables -A INPUT -p tcp --dport 123 -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j ACCEPT
#
#
# Set default policies for INPUT, FORWARD and OUTPUT chains
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
# Above used to be set to "DROP" but then the port forwarding didn't work for the VPN, so changed to "ACCEPT".
iptables -P OUTPUT ACCEPT
#
#
# Set access for localhost - necessary for many programs
iptables -A INPUT -i lo -j ACCEPT
#
#
# Accept packets belonging to established and related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
#
# Allows proper routing of VPN subnet
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
#
#
# Make and exception to 'iptables -P FORWARD DROP', allowing specifically 1194 connections to forward.
iptables -t nat -A PREROUTING -p udp --dport 1194 -j DNAT --to 192.168.0.5
#
#
# Save settings
/sbin/service iptables save
#
#
# List rules, verbose
iptables -L -v
~

Ser Olmy · 08-01-2013, 12:02 AM

You could move frequently matched rules to the top of the file. In particulsr I'd move the loopback rule and the state match to the top of the INPUT chain. It will have a positive effect on routing performance and/or CPU load.

The "-m state" match and the related "--state" parameter is deprecated and should be changed to "-m conntrack" and "--ctstate" respectively (provided your iptables executable is reasonably recent).

You should definitely change the FORWARD policy to DROP and add any necessary rules to allow VPN traffic instead.

ziphem · 08-01-2013, 06:14 PM

Ok, thanks a ton for the feedback, I've taken some of your suggestions. The conntrack and cstate didn't work with my version of IPTables however, unfortunately. I've since done the following:

Code:

#!/bin/bash
#
# iptables configuration script
#
# Flush all current rules from iptables
iptables -F
#
#
# Set access for localhost - necessary for many programs
iptables -A INPUT -i lo -j ACCEPT
#
#
# Accept packets belonging to established and related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
#
# Allow SSH connections on tcp port 123 and udp port 1194 (VPN)
iptables -A INPUT -p tcp --dport 123 -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j ACCEPT
#
#
# Allows VPN traffic to Forward
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
#
#
# Make and exception to 'iptables -P FORWARD DROP', allowing specifically 1194 connections to forward.
iptables -t nat -A PREROUTING -p udp --dport 1194 -j DNAT --to 192.168.0.5
#
#
# Set default policies for INPUT, FORWARD and OUTPUT chains
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
#
#
# Allows proper routing of VPN subnet
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
#
#
#
# Save settings
/sbin/service iptables save
#
#
# List rules, verbose
iptables -L -v
~

Thanks!!

ziphem · 08-18-2013, 01:32 PM

I can cannot fine to my VPN server now, that's fantastic. But I cannot connect through it to the internet - what am I not seeing with the lastest iptables configuration? It must be something with forwarding, but what am I doing wrong?

Thanks!

ziphem · 12-12-2013, 10:54 PM

I should close out this post as "solved" with the help I received. I also wanted to point out the (admittedly embarassing) error that I made that prevented me from connecting to the internet through my VPN, especially because it's been a while since I determined the mistake. I wanted to post in case someone else runs into the same error.

I was routing to eth0, when in fact it should have been to eth4....

Code:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth4 -j MASQUERADE

That's why I could connect to the PC via VPN, but could never connect past that to the internet!