# firewall issues [SOLVED]

## Stonic

Hey, I have been having some issues with my firewall/iptables.

I have a set of services set up that all require open ports on my server/router.  When I start up my firewall script, everything works great!  However, after approximately a day or two, some rules seem to not 'work' anymore.  For example, I use port 3784 for my vent server, when I start my firewall people can connect from the outside,  It's not until about two days when they can not connect, and I see one-way traffic on my external interface.  The rule still shows in iptables, and nothing seems to have changed.

This is what the list would look like:

```
Chain INPUT (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:8000 state NEW

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3784 state NEW

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh state NEW

REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset

REJECT     udp  --  anywhere             anywhere            reject-with icmp-port-unreachable
```

Now, the strange thing is, is that port 8000 is working properly remotely, and SSH as well.  This has also happened to me with my game server, it would work for 2 days than no one could connect to it.

Restarting my firewall script will solve the issue, but I'm looking for the cause of it now, any ideas?

I do notice that DHCP for my external interface does call for an IP address about every 1/2-2 days when it's lease expires, not sure if this has anything to do with it.

Edit: Here is a snippet of the traffic when I try to connect remotely:

```
IP 70.75.X.X > 69.46.X.X: ICMP 70.75.25.70 udp port 3784 unreachable, length 236

IP 69.46.X.X.48124 > 70.75.X.X.3784: UDP, length 200

IP 70.75.X.X > 69.46.X.X: ICMP 70.75.25.70 udp port 3784 unreachable, length 236

IP 69.46.X.X.48124 > 70.75.X.X.3784: UDP, length 200

```

Last edited by Stonic on Wed Jan 02, 2008 8:05 pm; edited 1 time in total

----------

## Hu

Please use iptables-save -c instead of iptables -L.  The former produces more detailed output, and is machine readable.  Is the Vent server running on the firewall, or on a host inside the LAN?  Your iptables rules suggest it is on the firewall system.  The firewall is 70.75.x.x, correct?

Your packet capture shows that the client is leading with a UDP packet, but you do not show any rules which would allow unsolicited UDP to ever penetrate the firewall.  Could you also show the first 10-20 packets exchanged during a successful connect?  I would like to see the protocol and port numbers used for those requests.

----------

## Malvineous

You might find that the services that break have been bound to an IP address rather than an interface.  If your IP is 1.2.3.4 and you run a server which binds to 1.2.3.4, then when your IP changes to 5.6.7.8 the server is still only listening on 1.2.3.4 so it ignores anything coming in on your new 5.6.7.8 IP.  SSH normally listens on all interfaces whatever their IPs might be, which is probably why it keeps working.  The normal error when this happens is "port unreachable", which seems to be what you're getting.

I'd check your server config for each service that breaks to make sure you're not restricting it to a particular IP.  If in doubt see if you can configure it to listen on all interfaces and then use iptables to block any you don't want instead.

Also, when you list your rules use the -v option, as this will also tell you which interface the rules are bound to, and how many packets have matched each rule (which is handy to keep an eye on if traffic isn't doing what you want - if the numbers go up you know which rule the packets are matching that you weren't expecting.)

Edit: Although the last rule in your firewall says to block all UDP traffic with "port unreachable" and then you show a sample of UDP traffic that's failing with a "port unreachable" error - it seems that this is the behaviour you have configured on purpose!  You will probably find that if you initiate a connection before the firewall has properly loaded (or while you're reloading it), it will be treated as an "established" connection and that early rule will match, because the connection has already been established.  After a couple of days however, the connection drops out of the server's cache and it no longer sees it as "established", at which time that last rule takes effect, which blocks all incoming UDP traffic from entering your machine.

----------

## Suicidal

You are allowing TCP traffic on 3784, but not UDP traffic.

```
netstat -nap | grep 3784

tcp        0      0 0.0.0.0:3784            0.0.0.0:*               LISTEN      7550/ventrilo_srv   

udp        0      0 0.0.0.0:3784            0.0.0.0:*                           7550/ventrilo_srv  
```

The following line in your iptables should open it:

```
iptables -A INPUT -p udp -m state --state NEW -m udp --dport 3784 -j ACCEPT
```

I also updated the ventrilo-server-bin ebuild (3.0.2) since the one in portage is outdated (2.3.1)

```
# Copyright 1999-2007 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

IUSE=""

DESCRIPTION="The Ventrilo Voice Communication Server"

HOMEPAGE="http://www.ventrilo.com/"

SRC_URI="ventrilo_srv-${PV}-Linux-i386.tar.gz"

LICENSE="ventrilo"

SLOT="0"

KEYWORDS="-* x86 amd64"

RESTRICT="fetch"

S=${WORKDIR}

DEPEND="amd64? ( app-emulation/emul-linux-x86-baselibs )"

pkg_nofetch() {

    einfo "Please visit http://www.ventrilo.com/download.php"

    einfo "and download the Linux i386 - 32bit ${PV} server."

    einfo "Just save it in ${DISTDIR} !"

}

src_install() {

    cd ${S}/ventsrv

    exeinto /opt/ventrilo-server

    doexe ventrilo_{srv,status}

    newinitd "${FILESDIR}"/init.d.ventrilo ventrilo

    newconfd "${FILESDIR}"/conf.d.ventrilo ventrilo

    insinto /opt/ventrilo-server

    doins ventrilo_srv.ini

    dohtml ventrilo_srv.htm

}
```

Actually check out my attachments to BUG 201136 there are alot of changes in that ebuild including the daemon not running as root.

----------

## Stonic

Thank you guys for your help.

I should pay more attention to the traffic lol, I had no idea it used UDP protocol, and that was definitely the problem.

I adjusted my firewall script to allow UDP traffic for that port and it's working great now!

----------

## Suicidal

Cool, when I saw TCP for voice it threw up a big red flag as most traffic like voice and gaming traffic uses UDP for low latency.

I think the TCP port is for ventrilo_status, which can be ran from a remote computer.

----------

