Hi, i have an smtp server running behind my firewall. Every day i have had the port forwarding stop working after approx 24 hours. I masquerade on the public ip and forward port 25 and 443 to the mail server.

From a remote server i try and telnet to port 25, all i get in the console is is "trying x.x.x.x..." and nothing happens. I can ssh into the actual openwrt router itself from the outside remote connection. Other ports forwarded to different machines also fail to work. There are only 15 users on the network so the load isnt massive, i am pretty sure people arent using p2p also (they shouldnt be!).

Upon rebooting the openwrt box and everything starts working fine again.

Conntrack Settings are as follows:

Maximum Connections - 5953
Generic Timeout - 600
ICMP Timeout - 30
TCP Established Timeout - 86400
UDP Timeout - 30
UDP Stream Timeout - 180

I know TCP established timeout is 24 hours and might be the problem however this problem also happened when the value was set to 1 hour: 3600 seconds. I hit the button to set the value to defaults which was 24 hours, but this seems a bit high to me. Any idea or recommendations what these values should be? I will try setting tcp established timeout to 3600 again and upping the max connections to 8000.

Settings are also below:

Many thanks in advance,

Chris

root@router:/etc/config# cat /etc/config/network
#### VLAN configuration
config switch eth0
        option vlan0    '1 2 5*'
        option vlan1    '3 4 5*'
        option vlan2    '0 5*'
        option vlan3    '5'

#### Loopback configuration
config interface loopback
        option ifname   "lo"
        option proto    static
        option ipaddr   127.0.0.1
        option netmask  255.0.0.0

#### LAN configuration
config interface lan
        option ifname   'eth0.0'
        option proto    static
        option ipaddr   '192.168.2.1'
        option netmask  255.255.255.0
        option gateway  ''
        option dns      ''

config interface lanmgmt
        option ifname   'eth0.1'
        option proto    static
        option ipaddr   '192.168.1.1'
        option netmask  255.255.255.0
        option gateway  ''
        option dns      ''

#### WAN configuration
config interface        wan
        option ifname   "eth0.2"
        option proto    'static'
        option dns      '213.132.33.15'
        option ipaddr   'x.x.x.x'
        option netmask  '255.255.255.252'
        option gateway  'x.x.x.x'

config interface wlunsec
    option type    "bridge"
    option ifname    "eth0.3"
    option proto    static
    option ipaddr    10.0.0.1
    option netmask    255.255.255.0
    option gateway    ''

root@router:~# cat /etc/firewall.user
#!/bin/sh
# Copyright (C) 2006 OpenWrt.org

iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule

# The following chains are for traffic directed at the IP of the
# WAN interface

iptables -F input_wan
iptables -F forwarding_wan
iptables -t nat -F prerouting_wan

### Open port to WAN
## -- This allows port 22 to be answered by (dropbear on) the router
# iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT
# iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT

### Port forwarding
## -- This forwards port 8080 on the WAN to port 80 on 192.168.1.2
# iptables -t nat -A prerouting_wan -p tcp --dport 8080 -j DNAT --to 192.168.1.2:80
# iptables        -A forwarding_wan -p tcp --dport 80 -d 192.168.1.2 -j ACCEPT

### DMZ
## -- Connections to ports not handled above will be forwarded to 192.168.1.2
# iptables -t nat -A prerouting_wan -j DNAT --to 192.168.1.2
# iptables        -A forwarding_wan -d 192.168.1.2 -j ACCEPT

iptables -A forwarding_rule -i eth0.0 -o eth0.1 -j ACCEPT
iptables -A forwarding_rule -i eth0.1 -o eth0.0 -j ACCEPT
iptables -A forwarding_rule -i eth0.1 -o eth0.2 -j ACCEPT
root@router:~#

/etc/config/firewall

forward:proto=udp dport=1194:192.168.2.245:1194
forward:proto=tcp dport=25:192.168.2.12:25
forward:proto=tcp dport=443:192.168.2.12:443
forward:proto=tcp dport=1196:192.168.2.245:22
accept:proto=tcp dest=x.x.x.x dport=22   #x.x.x.x = my public ip

(Last edited by g18c on 11 Dec 2007, 06:43)

The only thing I can think of that may be causing this is a cron job or some sort of daily work job that is clearing your iptables.

Nope this isnt the case, no cron job and i didnt mean 24 hours literally, its more random than that... other people have been having similair issues with the latest release and word is there are issues with iptables contracking modules.

Do you ip changes over time?

no, static ip. i read in another post about similair issues so i removed all of the entries in /etc/config/firewall, and added the iptables lines explicitly in /etc/firewall.user. The reasoning is if the target port is not specified then it will work, i.e. for the iptables rule instead of specifying --to $ip:$port only --to $ip should be specified. i.e. frostschutz from another post says that:

iptables -t nat -A prerouting_wan -p tcp --dport 25 -j DNAT --to 192.168.1.2
iptables        -A forwarding_wan -p tcp --dport 25 -d 192.168.1.2 -j ACCEPT

should work.

Unfortunatly this means i can only have 1:1 port mapping but if it stops this lock ups them i can live with that, i have just changed and rebooted the box and will post if this has fixed or not.

Will let you know, more interestingly has this been confirmed as a bug to the dev team?

what happens if you tcpdump on the public side when this errors out. do you see rst packets or ?

Hi, I think I have somehow the same problem with my KAMIKAZE (7.07) on Asus WL500gP when forwarding tcp ports for connecting to an internal ftp server from outside - internet. When rebooting the router, everything works fine but after a few hours I can not connect to ftp anymore. Packets from the ftp client still arrive to the router from the outside network as seen with tcpdump. I use PPPoE.

/etc/firewall.user  ftp port forwarding section

# ftp
iptables -t nat -A prerouting_wan -p tcp --dport 8021 -j DNAT --to 192.168.1.100:21
iptables        -A forwarding_wan -p tcp --dport 21 -d 192.168.1.100 -j ACCEPT

# ftp-data
iptables -t nat -A prerouting_wan -p tcp --dport 8020 -j DNAT --to 192.168.1.100:20
iptables        -A forwarding_wan -p tcp --dport 20 -d 192.168.1.100 -j ACCEPT

Hi, i can confirm the box has been up solid for the past 2 weeks since i removed the explicit port specification for the nat rule.

i.e.

iptables -t nat -A prerouting_wan -p tcp --dport 25 -j DNAT --to 192.168.1.2
iptables        -A forwarding_wan -p tcp --dport 25 -d 192.168.1.2 -j ACCEPT

instead of

iptables -t nat -A prerouting_wan -p tcp --dport 25 -j DNAT --to 192.168.1.2:25
iptables        -A forwarding_wan -p tcp --dport 25 -d 192.168.1.2 -j ACCEPT

This definetly works but i dont know why.

Cheers,

Chris

This appears to be a problem in netfilter.  For those experiencing the problem I would recommend reporting the problem to the netfilter team.  http://www.netfilter.org

(Last edited by lschweiss on 31 Dec 2007, 22:54)

Gonna refresh this.

Im having similar problem. I configured Forward in X-wrt(/etc/config/firewall) but it appears to stop working after some time.
Should I clear this config and forward ports only with iptables firewall.user file ?
Not quite sure what is the diffrence :S

I tried the 20080922 brcm-2.4 image (from the snapshots directory) and this problem still appears to be happening. Unfortunately it's preventing me using OpenWRT as my primary router (still using a Linux box). Is this still being looked at as an iptables bug?

Strange, I've also been experiencing this problem but it seems to have temporarily gone away - I've no idea why.

It's interesting to see others are experiencing it too so I'll keep an eye on it and see if i can work it out what it is that I'm doing to make it stop.

Any luck Siftah?

Nope - I had it happen to me yesterday but couldn't see anything in the logs, bit lost as to where to look to start debugging it to be honest.

Rebooting the router brought it back up, restarting the firewall didn't seem to work.

Are you using the qos-scripts package? Or does it just happen with a heavy traffic load?

Nope, qos-scripts aren't installed.

It doesn't seem to be related to traffic load as far as I can tell, I kicked off a load of torrents on Saturday and they were maxing out my bandwidth for most of Saturday, Sunday they'd finished downloading and traffic dropped off by the evening.

Monday/Tuesday there was very little traffic and I noticed the port forwards had died on Tuesday morning, so as far as I can tell it's happening regardless of traffic levels.