# [Solved] iptables init script kills connectivity

## cynric

A short summary has been added as the last post for those in too much of a hurry to read the entire thread

I used to have a Gentoo firewall running smoothly as of a few months ago. The system is a hardened x86 with modified firewall scripts based off those at HOWTO: Iptables for newbies. One day after a few minor updates and a kernel upgrade, I restarted the firewall only to find that all connectivity was lost. Fearing a bad upgrade, I rolled back the changes with no change. After a few days of frustration, I re-installed Gentoo fearing that perhaps the machine was compromised or at least in a state which I could not recover from.

A fresh install did not help the old script. Nor did it help a new script. Nor did it help a bare-bones, default ACCEPT policy. I've restarted my project to get this firewall back up and, of course, I am lacking connectivity with a default ACCEPT policy. In fact, after flushing and deleting all iptable chains, and no script the machine or hosts behind it can not ping out. All connection attempts are met with a name resolution error (not a big surprise here). If `/etc/init.d/iptables stop` is issued, connectivity comes back.

I am at quite a loss as to how to proceed. As I said, it's a gentoo hardened box with pax. No rsbac is enabled or chroots used. The system runs dnsmasq and dhcpcd. The latter two services appear to work, but without being able to connect to the box, I can not determine whether they are configured appropriately. If there was some script (I'll even go for a magical phrase at this point) that would give any connectivity it would help track down the problem(s).

So, if anyone has any ideas on what to check, possible commands that may be of use, general knowledge, etc I would be greatly appreciative. Any further or specific information that is needed, just ask. Thanks.

----------

## cynric

Disabling iptables allows hosts to get a dhcp address so that part is in fact working correctly. Still no progress on getting packets through the firewall with iptables enabled. Another interesting piece is that no logging is taking place. This makes me wonder if iptables is even receiving packets.

----------

## Hu

Please post the output of emerge --info, iptables -n -v -x --line-numbers -L -t nat, and iptables -n -v -x --line-numbers -L.  The emerge info is mainly for your kernel version, but it cannot hurt to have the rest of it there too.  The iptables commands are to get a full view of your policy.  Also, please cat /proc/sys/net/ipv4/ip_forward.  If this file is set to zero, the machine will not do IP forwarding, regardless of your NAT/filter policies.

If you have time, also emerge net-analyzer/tcpdump and capture an attempt to do name resolution while the iptables script is started.  This may show whether the message is getting lost going out or the response is getting filtered coming back.  Note that tcpdump output may contain sensitive information that you do not want disclosed.  If it does, feel free to filter it.

----------

## cynric

Many thanks for the reply and request of info. The iptables is really basic at this point as I'm just testing. It's  firewall.sh copied from HOWTO_Iptables_for_newbies. ip_forward is indeed set to 1. I'll post up a tcpdump capture later on this evening. For now though, here is the rest of the information you requested. This machine has 5 network cards (only two are active so far) and have been renamed via udev. I'll print this information too so that the iptables output makes more sense. Thanks again for taking a look at this.

ifconfig:

```
dmz       Link encap:Ethernet  HWaddr 00:04:5A:64:26:A6  

          inet addr:192.168.20.1  Bcast:192.168.20.255  Mask:255.255.255.0

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:2 dropped:0 overruns:0 carrier:4

          collisions:0 txqueuelen:1000 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:12 Base address:0xa000 

lan       Link encap:Ethernet  HWaddr 00:04:5A:82:4A:BB  

          inet addr:192.168.10.1  Bcast:192.168.10.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:51 errors:0 dropped:0 overruns:0 frame:0

          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:6280 (6.1 Kb)  TX bytes:3508 (3.4 Kb)

          Interrupt:4 Base address:0xa400 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:4 errors:0 dropped:0 overruns:0 frame:0

          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:352 (352.0 b)  TX bytes:352 (352.0 b)

log       Link encap:Ethernet  HWaddr 00:04:5A:63:6D:82  

          inet addr:192.168.30.1  Bcast:192.168.30.255  Mask:255.255.255.0

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:2 dropped:0 overruns:0 carrier:4

          collisions:0 txqueuelen:1000 

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:10 Base address:0x9800 

wlan      Link encap:Ethernet  HWaddr 00:04:5A:81:AF:19  

          inet addr:192.168.1.6  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:129 errors:0 dropped:0 overruns:0 frame:0

          TX packets:119 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:16777 (16.3 Kb)  TX bytes:24726 (24.1 Kb)

          Interrupt:4 Base address:0x9000
```

Emerge --info:

```
Portage 2.1.2.2 (hardened/x86/2.6, gcc-3.4.6, glibc-2.3.6-r5, 2.6.18-hardened i686)

=================================================================

System uname: 2.6.18-hardened i686 AMD Athlon(tm) Processor

Gentoo Base System release 1.12.9

Timestamp of tree: Thu, 26 Apr 2007 22:50:01 +0000

dev-lang/python:     2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.60

sys-devel/automake:  1.9.6-r2, 1.10

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.15-r1

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-march=athlon-tbird -mtune=athlon-tbird -O2 -fomit-frame-pointer -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc"

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"

CXXFLAGS="-march=athlon-tbird -mtune=athlon-tbird -O2 -fomit-frame-pointer -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv usersandbox"

GENTOO_MIRRORS="ftp://mirrors.tds.net/gentoo http://mirrors.tds.net/gentoo http://gentoo.seren.com/gentoo http://gentoo.mirrors.pair.com/"

MAKEOPTS="-j2"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_EXTRA_OPTS="--timeout=100"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"

USE="berkdb crypt hardened midi nptl nptlonly pam pic readline ssl tcpd x86 xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTDIR_OVERLAY
```

iptables -n -v -x --line-numbers -L -t nat:

```
Chain PREROUTING (policy ACCEPT 12 packets, 1874 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

1           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain POSTROUTING (policy ACCEPT 3 packets, 470 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

1           0        0 MASQUERADE  all  --  *      wlan    0.0.0.0/0            0.0.0.0/0           

2           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 3 packets, 470 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

1           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
```

iptables -n -v -x --line-numbers -L:

```
Chain INPUT (policy ACCEPT 14 packets, 2052 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

1           0        0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:113 flags:0x17/0x02 state NEW 

2           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

1           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT 11 packets, 1352 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

1           0        0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
```

----------

## cyberjun

Hi,

      This may be a shot in the dark. The conntrack option in IPTABLES has again changed between kernel versions 2.6.19 and 2.6.20. Have you enabled the options "IPv4 connection tracking support"  and "Netfilter connection tracking support" (I assume you have upgraded from 2.6.19 to 2.6.20)?

--cyberjun

EDIT: They have moved many options between IP: NETFILTER CONFIGURATION and CORE NETFILTER CONFIGURATION. Check all of them properly.

----------

## cynric

I'm not overly familiar with tcpdump and am still playing with it. However, for discussion, with iptables enabled and listening on the "lan" interface, BOOTP/DHCP Requests keep coming in with no BOOTP/DHCP Replies. I don't see how these replies out "lan" would be dropped by iptables since as far as I can tell, everything ought to be accepted.

With iptables off, both the Requests and Replies show up. When attempting a simple ping, it just times out on the host end. Watching tcpdump, "<mss 1460,nop,nop,sackOK>" shows up to coincide with the host timeout.

If a full log (only 34 packets with iptables enabled) is needed, I can put it up. The command I'm currently using is: 

```
tcpdump -lan -nN -xX host 192.168.10.90
```

Host 192.168.10.90 is a statically assigned address to a machine on the "lan" side via DHCP. Hope that's enough to keep help coming for now. If anyone wants the output of a different tcpdump variation, I'd be glad to post it. Thanks thus far.

----------

## cynric

cyberjun:

I'm running a stable hardened server so 2.6.8-r6 is the latest version available to me. Currently I'm running 2.6.8. Since this problem has persisted across a few other minor kernel upgrades, I'm assuming that it's not so much a kernel problem, but perhaps a misconfiguration on my end at best. As such, here are the relevant entries of my current kernel:

```
CONFIG_IP_NF_CONNTRACK=y

CONFIG_IP_NF_CT_ACCT=y

CONFIG_IP_NF_CONNTRACK_MARK=y

CONFIG_IP_NF_FTP=y

CONFIG_IP_NF_IPTABLES=y

CONFIG_IP_NF_MATCH_IPRANGE=y

CONFIG_IP_NF_MATCH_TOS=y

CONFIG_IP_NF_MATCH_RECENT=y

CONFIG_IP_NF_MATCH_ADDRTYPE=y

CONFIG_IP_NF_MATCH_STEALTH=y

CONFIG_IP_NF_FILTER=y

CONFIG_IP_NF_TARGET_REJECT=y

CONFIG_IP_NF_TARGET_LOG=y

CONFIG_IP_NF_NAT=y

CONFIG_IP_NF_NAT_NEEDED=y

CONFIG_IP_NF_TARGET_MASQUERADE=y

CONFIG_IP_NF_TARGET_REDIRECT=y

CONFIG_IP_NF_TARGET_NETMAP=y

CONFIG_IP_NF_TARGET_SAME=y

CONFIG_IP_NF_NAT_FTP=y

CONFIG_IP_NF_MANGLE=y

CONFIG_IP_NF_TARGET_TOS=y

CONFIG_IP_NF_ARPTABLES=y

CONFIG_NETFILTER=y

CONFIG_NETFILTER_NETLINK=y

CONFIG_NETFILTER_XTABLES=y

CONFIG_NETFILTER_XT_TARGET_MARK=y

CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y

CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y

CONFIG_NETFILTER_XT_MATCH_HELPER=y

CONFIG_NETFILTER_XT_MATCH_LIMIT=y

CONFIG_NETFILTER_XT_MATCH_MAC=y

CONFIG_NETFILTER_XT_MATCH_MARK=y

CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y

CONFIG_NETFILTER_XT_MATCH_STATE=y
```

Both connection tracking options appear to be enabled. I've hesitated upgrading the kernel to -r6 so as to keep everything consistent while conversing here. If there are known problems however, I would not be opposed to upgrading -- even to an unstable version. Thanks for the input.

----------

## Hu

Your kernel configuration includes support for the mangle table.  Please include the results of iptables -n -v -x --line-numbers -L -t mangle in both the iptables requests below, and post its output for the state where the script has just started the firewall.

 *cynric wrote:*   

> I'm not overly familiar with tcpdump and am still playing with it. However, for discussion, with iptables enabled and listening on the "lan" interface, BOOTP/DHCP Requests keep coming in with no BOOTP/DHCP Replies. I don't see how these replies out "lan" would be dropped by iptables since as far as I can tell, everything ought to be accepted.

 

They may not be dropped on output.  The incoming data shown by tcpdump is captured before the firewall processes it, so you can see packets that are subsequently dropped without reaching a host application.  Nothing in your rules strikes me as wrong, and I cannot explain how a system consisting entirely of ACCEPT rules could be dropping anything.  Please do the following:

Start iptables via the script.

Manually flush the rules as described in your first post.

Run the iptables listing commands.

Stop iptables via the script.

Run the iptables listing commands again.

This may give some insight into how stopping it via the script resolves the issue, when stopping it by hand does not.

From examining /etc/init.d/iptables, it appears that its "stop" action is just a flush, delete chains, and policy reset.

 *cynric wrote:*   

> With iptables off, both the Requests and Replies show up. When attempting a simple ping, it just times out on the host end. Watching tcpdump, "<mss 1460,nop,nop,sackOK>" shows up to coincide with the host timeout.
> 
> If a full log (only 34 packets with iptables enabled) is needed, I can put it up. The command I'm currently using is: 
> 
> ```
> ...

 

Go ahead and post the tcpdump output.  Also, please try a capture with the firewalled box pinging out by IP address.  If the packets never leave the machine, that implicates the output chains as eating the traffic.  If traffic leaves the machine, but tcpdump never sees it come back, then the peer is dropping or misrouting the traffic.  If the traffic returns, but ping reports timeout, that implicates the input chains.

----------

## cynric

 *Hu wrote:*   

> They may not be dropped on output.  The incoming data shown by tcpdump is captured before the firewall processes it, so you can see packets that are subsequently dropped without reaching a host application.  Nothing in your rules strikes me as wrong, and I cannot explain how a system consisting entirely of ACCEPT rules could be dropping anything.

 

True. Thanks for the comfirmation on the rules. After having lengthy problems, one begins to doubt themselves.

Here is the mangle output.

iptables -n -v -x --line-numbers -L -t mangle:

```
Chain PREROUTING (policy ACCEPT 4 packets, 313 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy DROP 4 packets, 313 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy DROP 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 32 packets, 2080 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy DROP 32 packets, 2080 bytes)

num      pkts      bytes target     prot opt in     out     source               destination
```

 *Hu wrote:*   

> Please do the following:
> 
> Start iptables via the script.
> 
> Manually flush the rules as described in your first post.
> ...

 

Just to keep everything recorded, here are the commands to be executed. Output printed below.

```
/etc/init.d/iptables stop

/etc/init.d/iptables start

iptables -F

iptables -F -t nat

iptables -F -t mangle

iptables -X

iptables -X -t nat

iptables -X -t mangle

iptables -n -v -x --line-numbers -L > 1_ipt_L.txt

iptables -n -v -x --line-numbers -L -t nat > 1_ipt_nat.txt

iptables -n -v -x --line-numbers -L -t mangle > 1_ipt_man.txt

/etc/init.d/iptables stop

iptables -n -v -x --line-numbers -L > 2_ipt_L.txt

iptables -n -v -x --line-numbers -L -t nat > 2_ipt_nat.txt

iptables -n -v -x --line-numbers -L -t mangle > 2_ipt_man.txt
```

1_ipt_L.txt:

```
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 20 packets, 1300 bytes)

num      pkts      bytes target     prot opt in     out     source               destination
```

1_ipt_nat.txt:

```
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4 packets, 260 bytes)

num      pkts      bytes target     prot opt in     out     source               destination
```

1_ipt_man.txt:

```
Chain PREROUTING (policy ACCEPT 6 packets, 369 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy DROP 6 packets, 369 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy DROP 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 32 packets, 2080 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy DROP 32 packets, 2080 bytes)

num      pkts      bytes target     prot opt in     out     source               destination
```

2_ipt_L.txt:

```
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination
```

2_ipt_nat.txt:

```
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination
```

2_ipt_man.txt:

```
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)

num      pkts      bytes target     prot opt in     out     source               destination
```

 *Hu wrote:*   

> Go ahead and post the tcpdump output. Also, please try a capture with the firewalled box pinging out by IP address.

 

If the below is not what you were expecting, I simply misunderstood your request.

Here is the tcpdump previously mentioned -- the DHCP attempt from a host behind the firewall.

tcpdump -i lan -nN -xX host 192.168.10.90:

```
11:59:24.903792 arp who-has 192.168.10.1 tell 192.168.10.90

        0x0000:  0001 0800 0604 0001 00c0 9fca 1837 c0a8  .............7..

        0x0010:  0a5a 0000 0000 0000 c0a8 0a01 0000 0000  .Z..............

        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

11:59:24.903976 arp reply 192.168.10.1 is-at 00:04:5a:82:4a:bb

        0x0000:  0001 0800 0604 0002 0004 5a82 4abb c0a8  ..........Z.J...

        0x0010:  0a01 00c0 9fca 1837 c0a8 0a5a            .......7...Z

11:59:26.098505 arp who-has 192.168.10.1 tell 192.168.10.90

        0x0000:  0001 0800 0604 0001 00c0 9fca 1837 c0a8  .............7..

        0x0010:  0a5a 0000 0000 0000 c0a8 0a01 0000 0000  .Z..............

        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

11:59:26.098513 arp reply 192.168.10.1 is-at 00:04:5a:82:4a:bb

        0x0000:  0001 0800 0604 0002 0004 5a82 4abb c0a8  ..........Z.J...

        0x0010:  0a01 00c0 9fca 1837 c0a8 0a5a            .......7...Z

11:59:27.239642 arp who-has 192.168.10.1 tell 192.168.10.90

        0x0000:  0001 0800 0604 0001 00c0 9fca 1837 c0a8  .............7..

        0x0010:  0a5a 0000 0000 0000 c0a8 0a01 0000 0000  .Z..............

        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

11:59:27.239650 arp reply 192.168.10.1 is-at 00:04:5a:82:4a:bb

        0x0000:  0001 0800 0604 0002 0004 5a82 4abb c0a8  ..........Z.J...

        0x0010:  0a01 00c0 9fca 1837 c0a8 0a5a            .......7...Z

11:59:29.288868 IP 192.168.10.90.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

        0x0000:  4500 0148 591b 0000 8011 1588 c0a8 0a5a  E..HY..........Z

        0x0010:  ffff ffff 0044 0043 0134 77b9 0101 0600  .....D.C.4w.....

        0x0020:  a5ca 27fd 0000 0000 c0a8 0a5a 0000 0000  ..'........Z....

        0x0030:  0000 0000 0000                           ......

11:59:32.285539 IP 192.168.10.90.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

        0x0000:  4500 0148 591e 0000 8011 1585 c0a8 0a5a  E..HY..........Z

        0x0010:  ffff ffff 0044 0043 0134 74b9 0101 0600  .....D.C.4t.....

        0x0020:  a5ca 27fd 0300 0000 c0a8 0a5a 0000 0000  ..'........Z....

        0x0030:  0000 0000 0000                           ......

11:59:33.238427 arp who-has 192.168.10.1 tell 192.168.10.90

        0x0000:  0001 0800 0604 0001 00c0 9fca 1837 c0a8  .............7..

        0x0010:  0a5a 0000 0000 0000 c0a8 0a01 0000 0000  .Z..............

        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

11:59:33.238450 arp reply 192.168.10.1 is-at 00:04:5a:82:4a:bb

        0x0000:  0001 0800 0604 0002 0004 5a82 4abb c0a8  ..........Z.J...

        0x0010:  0a01 00c0 9fca 1837 c0a8 0a5a            .......7...Z

11:59:33.238793 IP 192.168.10.90.1924 > 192.168.10.1.53:  3801+[|domain]

        0x0000:  4500 0044 591f 0000 8011 4bde c0a8 0a5a  E..DY.....K....Z

        0x0010:  c0a8 0a01 0784 0035 0030 4238 0ed9 0100  .......5.0B8....

        0x0020:  0001 0000 0000 0000 0763 7572 7265 6e74  .........current

        0x0030:  0363 7664 0663                           .cvd.c

11:59:37.115054 IP 192.168.10.90.1078 > 192.168.10.1.53:  22139+[|domain]

        0x0000:  4500 003e 5920 0000 8011 4be3 c0a8 0a5a  E..>Y.....K....Z

        0x0010:  c0a8 0a01 0436 0035 002a 1b45 567b 0100  .....6.5.*.EV{..

        0x0020:  0001 0000 0000 0000 0363 6d32 087a 6f6e  .........cm2.zon

        0x0030:  656c 6162 7303                           elabs.

11:59:38.112555 IP 192.168.10.90.1078 > 192.168.10.1.53:  22139+[|domain]

        0x0000:  4500 003e 5921 0000 8011 4be2 c0a8 0a5a  E..>Y!....K....Z

        0x0010:  c0a8 0a01 0436 0035 002a 1b45 567b 0100  .....6.5.*.EV{..

        0x0020:  0001 0000 0000 0000 0363 6d32 087a 6f6e  .........cm2.zon

        0x0030:  656c 6162 7303                           elabs.

11:59:39.112372 IP 192.168.10.90.1078 > 192.168.10.1.53:  22139+[|domain]

        0x0000:  4500 003e 5924 0000 8011 4bdf c0a8 0a5a  E..>Y$....K....Z

        0x0010:  c0a8 0a01 0436 0035 002a 1b45 567b 0100  .....6.5.*.EV{..

        0x0020:  0001 0000 0000 0000 0363 6d32 087a 6f6e  .........cm2.zon

        0x0030:  656c 6162 7303                           elabs.

11:59:40.245227 IP 192.168.10.90.1025 > 192.168.10.1.53:  36216+[|domain]

        0x0000:  4500 0041 5925 0000 8011 4bdb c0a8 0a5a  E..AY%....K....Z

        0x0010:  c0a8 0a01 0401 0035 002d b451 8d78 0100  .......5.-.Q.x..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:40.293070 IP 192.168.10.90.1077 > 192.168.10.1.53:  26232+ A? wpad. (22)

        0x0000:  4500 0032 5926 0000 8011 4be9 c0a8 0a5a  E..2Y&....K....Z

        0x0010:  c0a8 0a01 0435 0035 001e 2548 6678 0100  .....5.5..%Hfx..

        0x0020:  0001 0000 0000 0000 0477 7061 6400 0001  .........wpad...

        0x0030:  0001                                     ..

11:59:40.296088 IP 192.168.10.90.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

        0x0000:  4500 014a 5927 0000 8011 157a c0a8 0a5a  E..JY'.....z...Z

        0x0010:  ffff ffff 0044 0043 0136 3ab3 0101 0600  .....D.C.6:.....

        0x0020:  4155 10b7 0000 0000 c0a8 0a5a 0000 0000  AU.........Z....

        0x0030:  0000 0000 0000                           ......

11:59:41.112105 IP 192.168.10.90.1078 > 192.168.10.1.53:  22139+[|domain]

        0x0000:  4500 003e 5928 0000 8011 4bdb c0a8 0a5a  E..>Y(....K....Z

        0x0010:  c0a8 0a01 0436 0035 002a 1b45 567b 0100  .....6.5.*.EV{..

        0x0020:  0001 0000 0000 0000 0363 6d32 087a 6f6e  .........cm2.zon

        0x0030:  656c 6162 7303                           elabs.

11:59:41.236947 IP 192.168.10.90.1025 > 192.168.10.1.53:  36216+[|domain]

        0x0000:  4500 0041 5929 0000 8011 4bd7 c0a8 0a5a  E..AY)....K....Z

        0x0010:  c0a8 0a01 0401 0035 002d b451 8d78 0100  .......5.-.Q.x..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:41.283986 IP 192.168.10.90.1077 > 192.168.10.1.53:  26232+ A? wpad. (22)

        0x0000:  4500 0032 592a 0000 8011 4be5 c0a8 0a5a  E..2Y*....K....Z

        0x0010:  c0a8 0a01 0435 0035 001e 2548 6678 0100  .....5.5..%Hfx..

        0x0020:  0001 0000 0000 0000 0477 7061 6400 0001  .........wpad...

        0x0030:  0001                                     ..

11:59:42.237330 IP 192.168.10.90.1025 > 192.168.10.1.53:  36216+[|domain]

        0x0000:  4500 0041 592b 0000 8011 4bd5 c0a8 0a5a  E..AY+....K....Z

        0x0010:  c0a8 0a01 0401 0035 002d b451 8d78 0100  .......5.-.Q.x..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:42.283435 IP 192.168.10.90.1077 > 192.168.10.1.53:  26232+ A? wpad. (22)

        0x0000:  4500 0032 592c 0000 8011 4be3 c0a8 0a5a  E..2Y,....K....Z

        0x0010:  c0a8 0a01 0435 0035 001e 2548 6678 0100  .....5.5..%Hfx..

        0x0020:  0001 0000 0000 0000 0477 7061 6400 0001  .........wpad...

        0x0030:  0001                                     ..

11:59:43.284349 IP 192.168.10.90.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

        0x0000:  4500 014a 592d 0000 8011 1574 c0a8 0a5a  E..JY-.....t...Z

        0x0010:  ffff ffff 0044 0043 0136 37b3 0101 0600  .....D.C.67.....

        0x0020:  4155 10b7 0300 0000 c0a8 0a5a 0000 0000  AU.........Z....

        0x0030:  0000 0000 0000                           ......

11:59:44.236853 IP 192.168.10.90.1025 > 192.168.10.1.53:  36216+[|domain]

        0x0000:  4500 0041 592e 0000 8011 4bd2 c0a8 0a5a  E..AY.....K....Z

        0x0010:  c0a8 0a01 0401 0035 002d b451 8d78 0100  .......5.-.Q.x..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:44.283133 IP 192.168.10.90.1077 > 192.168.10.1.53:  26232+ A? wpad. (22)

        0x0000:  4500 0032 592f 0000 8011 4be0 c0a8 0a5a  E..2Y/....K....Z

        0x0010:  c0a8 0a01 0435 0035 001e 2548 6678 0100  .....5.5..%Hfx..

        0x0020:  0001 0000 0000 0000 0477 7061 6400 0001  .........wpad...

        0x0030:  0001                                     ..

11:59:45.111683 IP 192.168.10.90.1078 > 192.168.10.1.53:  22139+[|domain]

        0x0000:  4500 003e 5930 0000 8011 4bd3 c0a8 0a5a  E..>Y0....K....Z

        0x0010:  c0a8 0a01 0436 0035 002a 1b45 567b 0100  .....6.5.*.EV{..

        0x0020:  0001 0000 0000 0000 0363 6d32 087a 6f6e  .........cm2.zon

        0x0030:  656c 6162 7303                           elabs.

11:59:48.236180 IP 192.168.10.90.1025 > 192.168.10.1.53:  36216+[|domain]

        0x0000:  4500 0041 5931 0000 8011 4bcf c0a8 0a5a  E..AY1....K....Z

        0x0010:  c0a8 0a01 0401 0035 002d b451 8d78 0100  .......5.-.Q.x..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:48.282794 IP 192.168.10.90.1077 > 192.168.10.1.53:  26232+ A? wpad. (22)

        0x0000:  4500 0032 5932 0000 8011 4bdd c0a8 0a5a  E..2Y2....K....Z

        0x0010:  c0a8 0a01 0435 0035 001e 2548 6678 0100  .....5.5..%Hfx..

        0x0020:  0001 0000 0000 0000 0477 7061 6400 0001  .........wpad...

        0x0030:  0001                                     ..

11:59:50.283400 IP 192.168.10.90.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]

        0x0000:  4500 014a 5933 0000 8011 156e c0a8 0a5a  E..JY3.....n...Z

        0x0010:  ffff ffff 0044 0043 0136 30b3 0101 0600  .....D.C.60.....

        0x0020:  4155 10b7 0a00 0000 c0a8 0a5a 0000 0000  AU.........Z....

        0x0030:  0000 0000 0000                           ......

11:59:52.112253 IP 192.168.10.90.1932 > 208.185.174.65.443: S 4128716070:4128716070(0) win 16384 <mss 1460,nop,nop,sackOK>

        0x0000:  4500 0030 5934 4000 8006 5796 c0a8 0a5a  E..0Y4@...W....Z

        0x0010:  d0b9 ae41 078c 01bb f617 3526 0000 0000  ...A......5&....

        0x0020:  7002 4000 c49c 0000 0204 05b4 0101 0402  p.@.............

11:59:55.062724 IP 192.168.10.90.1932 > 208.185.174.65.443: S 4128716070:4128716070(0) win 16384 <mss 1460,nop,nop,sackOK>

        0x0000:  4500 0030 5937 4000 8006 5793 c0a8 0a5a  E..0Y7@...W....Z

        0x0010:  d0b9 ae41 078c 01bb f617 3526 0000 0000  ...A......5&....

        0x0020:  7002 4000 c49c 0000 0204 05b4 0101 0402  p.@.............

11:59:55.239164 IP 192.168.10.90.1078 > 192.168.10.1.53:  9081+[|domain]

        0x0000:  4500 0041 5938 0000 8011 4bc8 c0a8 0a5a  E..AY8....K....Z

        0x0010:  c0a8 0a01 0436 0035 002d 1e1c 2379 0100  .....6.5.-..#y..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:55.298637 IP 192.168.10.90.1077 > 192.168.10.1.53:  1406+[|domain]

        0x0000:  4500 004c 5939 0000 8011 4bbc c0a8 0a5a  E..LY9....K....Z

        0x0010:  c0a8 0a01 0435 0035 0038 339e 057e 0100  .....5.5.83..~..

        0x0020:  0001 0000 0000 0000 0276 350d 7769 6e64  .........v5.wind

        0x0030:  6f77 7375 7064                           owsupd

11:59:56.235448 IP 192.168.10.90.1078 > 192.168.10.1.53:  9081+[|domain]

        0x0000:  4500 0041 593a 0000 8011 4bc6 c0a8 0a5a  E..AY:....K....Z

        0x0010:  c0a8 0a01 0436 0035 002d 1e1c 2379 0100  .....6.5.-..#y..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:56.297164 IP 192.168.10.90.1077 > 192.168.10.1.53:  1406+[|domain]

        0x0000:  4500 004c 593b 0000 8011 4bba c0a8 0a5a  E..LY;....K....Z

        0x0010:  c0a8 0a01 0435 0035 0038 339e 057e 0100  .....5.5.83..~..

        0x0020:  0001 0000 0000 0000 0276 350d 7769 6e64  .........v5.wind

        0x0030:  6f77 7375 7064                           owsupd

11:59:57.235177 IP 192.168.10.90.1078 > 192.168.10.1.53:  9081+[|domain]

        0x0000:  4500 0041 593c 0000 8011 4bc4 c0a8 0a5a  E..AY<....K....Z

        0x0010:  c0a8 0a01 0436 0035 002d 1e1c 2379 0100  .....6.5.-..#y..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:57.297015 IP 192.168.10.90.1077 > 192.168.10.1.53:  1406+[|domain]

        0x0000:  4500 004c 593d 0000 8011 4bb8 c0a8 0a5a  E..LY=....K....Z

        0x0010:  c0a8 0a01 0435 0035 0038 339e 057e 0100  .....5.5.83..~..

        0x0020:  0001 0000 0000 0000 0276 350d 7769 6e64  .........v5.wind

        0x0030:  6f77 7375 7064                           owsupd

11:59:59.234672 IP 192.168.10.90.1078 > 192.168.10.1.53:  9081+[|domain]

        0x0000:  4500 0041 593e 0000 8011 4bc2 c0a8 0a5a  E..AY>....K....Z

        0x0010:  c0a8 0a01 0436 0035 002d 1e1c 2379 0100  .....6.5.-..#y..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

11:59:59.296730 IP 192.168.10.90.1077 > 192.168.10.1.53:  1406+[|domain]

        0x0000:  4500 004c 593f 0000 8011 4bb6 c0a8 0a5a  E..LY?....K....Z

        0x0010:  c0a8 0a01 0435 0035 0038 339e 057e 0100  .....5.5.83..~..

        0x0020:  0001 0000 0000 0000 0276 350d 7769 6e64  .........v5.wind

        0x0030:  6f77 7375 7064                           owsupd

12:00:01.077532 IP 192.168.10.90.1932 > 208.185.174.65.443: S 4128716070:4128716070(0) win 16384 <mss 1460,nop,nop,sackOK>

        0x0000:  4500 0030 5940 4000 8006 578a c0a8 0a5a  E..0Y@@...W....Z

        0x0010:  d0b9 ae41 078c 01bb f617 3526 0000 0000  ...A......5&....

        0x0020:  7002 4000 c49c 0000 0204 05b4 0101 0402  p.@.............

12:00:03.234134 IP 192.168.10.90.1078 > 192.168.10.1.53:  9081+[|domain]

        0x0000:  4500 0041 5941 0000 8011 4bbf c0a8 0a5a  E..AYA....K....Z

        0x0010:  c0a8 0a01 0436 0035 002d 1e1c 2379 0100  .....6.5.-..#y..

        0x0020:  0001 0000 0000 0000 0864 6174 6162 6173  .........databas

        0x0030:  6506 636c 616d                           e.clam

12:00:03.296224 IP 192.168.10.90.1077 > 192.168.10.1.53:  1406+[|domain]

        0x0000:  4500 004c 5942 0000 8011 4bb3 c0a8 0a5a  E..LYB....K....Z

        0x0010:  c0a8 0a01 0435 0035 0038 339e 057e 0100  .....5.5.83..~..

        0x0020:  0001 0000 0000 0000 0276 350d 7769 6e64  .........v5.wind

        0x0030:  6f77 7375 7064                           owsupd
```

Here is the tcpdump of the host trying to ping yahoo.com (66.94.234.13) after DHCP traffic dies.

tcpdump -i lan -nN -xX host 192.168.10.90:

```
12:12:48.194568 IP 192.168.10.90 > 66.94.234.13: ICMP echo request, id 512, seq 7424, length 40

        0x0000:  4500 003c 59cb 0000 8001 e987 c0a8 0a5a  E..<Y..........Z

        0x0010:  425e ea0d 0800 2e5c 0200 1d00 6162 6364  B^.....\....abcd

        0x0020:  6566 6768 696a 6b6c 6d6e 6f70 7172 7374  efghijklmnopqrst

        0x0030:  7576 7761 6263                           uvwabc

12:12:53.631001 IP 192.168.10.90 > 66.94.234.13: ICMP echo request, id 512, seq 7680, length 40

        0x0000:  4500 003c 59ce 0000 8001 e984 c0a8 0a5a  E..<Y..........Z

        0x0010:  425e ea0d 0800 2d5c 0200 1e00 6162 6364  B^....-\....abcd

        0x0020:  6566 6768 696a 6b6c 6d6e 6f70 7172 7374  efghijklmnopqrst

        0x0030:  7576 7761 6263                           uvwabc

12:12:59.130145 IP 192.168.10.90 > 66.94.234.13: ICMP echo request, id 512, seq 7936, length 40

        0x0000:  4500 003c 59cf 0000 8001 e983 c0a8 0a5a  E..<Y..........Z

        0x0010:  425e ea0d 0800 2c5c 0200 1f00 6162 6364  B^....,\....abcd

        0x0020:  6566 6768 696a 6b6c 6d6e 6f70 7172 7374  efghijklmnopqrst

        0x0030:  7576 7761 6263                           uvwabc

12:13:04.629476 IP 192.168.10.90 > 66.94.234.13: ICMP echo request, id 512, seq 8192, length 40

        0x0000:  4500 003c 59d0 0000 8001 e982 c0a8 0a5a  E..<Y..........Z

        0x0010:  425e ea0d 0800 2b5c 0200 2000 6162 6364  B^....+\....abcd

        0x0020:  6566 6768 696a 6b6c 6d6e 6f70 7172 7374  efghijklmnopqrst

        0x0030:  7576 7761 6263                           uvwabc
```

I was going to provide a tcpdump of the same ping from the perspective of the "wlan" interface assuming that by monitoring that interface it will show whether the packets are being switched from the "lan" to "wlan" interface. Nothing showed up belonging to yahoo or the host.

I was thinking that pinging out would be impossible from the host as it wouldn't have an IP address since it's DHCP assigned from the firewall. However, it must be using the IP obtained when iptables was disabled and since no DHCP reply is sent from the firewall, that information isn't flushed or updated.

Again, I'm not overly fluent in diagnosising, but it seems like the "lan" interface is receiving just fine. At this point, if that is true, then the problem lies in whether the data is getting from the interface to software or from software back to the interface. Since the only software in question is iptables (everything else appears to work just fine when iptables is disabled), then it's whether or not iptables is receiving the data (hardware problem?) and what iptables is doing with it (software). I decided to watch /var/log/messages for DHCP activity. It did light up with DHCPREQUEST and DHCPACK. So, that should mean that it's getting through iptables to dhcpcd. That leaves it hanging up getting back to iptables, since nothing (from what I can tell) shows up in the tcpdump from DHCP.

I'm not totally sure what that means other than a possible misconfiguration outside of the iptables scope. Just tossing this out there for feedback. One thing definitive about the logs is that the Flushing and Deletion of mangle via the iptables command does not appear to work (diff 1_ipt_man.txt 2_ipt_man.txt).

Hopefully this covered your requests. I appreciate you taking your time to dig through these logs.

----------

## Hu

Those were exactly the commands I wanted run.  I appreciate your patience digging through the possibilities.

Based on the new output, I think your mangle table is the problem.  When you clear the tables by hand, you are removing user-defined rules and deleting user-defined chains, but not resetting the chain's default policy.  You said in your original post that you were resetting the default policy, but I suspect you were only doing that for filter and maybe nat.

For filter and nat, not resetting the policy works because those have an ACCEPT policy even when the firewall is loaded.  However, the INPUT, FORWARD, and POSTROUTING chains in the mangle table have a policy of DROP.  Since you are not resetting that in your manual changes, the firewall starts dropping traffic.  The /etc/init.d/iptables script runs -F and -X for all the tables and resets the policy to ACCEPT for each chain.  Look for references to set_table_policy in /etc/init.d/iptables to see what it is doing.

 *cynric wrote:*   

> One thing definitive about the logs is that the Flushing and Deletion of mangle via the iptables command does not appear to work (diff 1_ipt_man.txt 2_ipt_man.txt).

 

It does work, but it may not be doing what you think.  According to the documentation, flushing is equivalent to deleting each rule by hand.  Deletion removes user-defined chains.  Neither of them changes the policy on the chain.  To do that, you must use iptables -P $CHAIN $NEW_POLICY.

However, I cannot explain the behavior with ping, other than to speculate that there may be an additional problem that is interfering with sending ICMP echo requests to the Internet.

So the new question becomes: what did you put in your ruleset that caused your mangle table to acquire a default policy of DROP and no associated rules to allow traffic?  The ruleset is stored in $IPTABLES_SAVE, which is /var/lib/iptables/rules-save on my system.  You can find the value by looking in /etc/conf.d/iptables.

----------

## cynric

You are absolutely right about the problem lying within the mangle table. Although it's rather obvious, I do not think reseting the policy would have ever hit me -- mostly because I've only seen PREROUTING and OUTPUT set in the mangle table. Setting the rest to ACCEPT allows the firewall to function normally with iptables enabled. The host machine behind the firewall is still mucked up, but now that I've found the root problem this changes the focus from an unknown problem to looking at the "lan" portion.

So, the firewall machine is working as of now. I'll continue working on the host machine. Hopefully with some more reading, testing, and keeping an eye out for that policy this should wrap up soon. I appreciate the immense help you've distributed, Hu. Once the "lan" interface works properly I'll probably recap this thread in a short summary in case someone else may find it useful. Thanks again for your time.

----------

## cynric

After adding the mangle policy commands to the script, traffic is flowing once more. Of course this is a Default Accept script for testing purposes, but it does conclude this thread. In case anyone is looking for a summary, here is a brief one. Of course, part or all of this may be natural to some, others may find this useful. If you don't know what all this means, then this is at least a place to start accumulating data so that others can help you. Good luck with future problems and a big thanks to Hu for his time and insight.

Short summary of this thread: (read entire thread for specifics)

Ensure that all the necessary kernel options are compiled or if they are modules, loaded (use lsmod to check).

When posting configs, try to remove all comments from your output. Try (pardon me for non-elegant solutions) one of the following. The first one is more helpful for kernel searches where you only want to search part of the file (for all NETFILTER occurances). The second one just strips all comments out and no searching.

```
grep NETFILTER /usr/src/linux/.config |grep -vh '^[[:space:]]*\(#\|$\)'

grep -vh '^[[:space:]]*\(#\|$\)' /usr/src/linux/.config
```

Checking the current iptables and all other tables that have been enabled (nat and mangle) as such:

```
iptables -n -v -x --line-numbers -L

iptables -n -v -x --line-numbers -L -t nat

iptables -n -v -x --line-numbers -L -t mangle
```

Remember that each chain for each table has it's own default policy that can be set (as shown with the commands above).

tcpdump is useful for listening on a device to determine whether traffic is getting in or out.

Although the init script for iptables clears and resets policies, once it's restarted, it reads from a text file (see Hu's post below) to reconfigure iptables to the state at which you last saved it. So, stopping and starting will not give you a fresh slate if your last save state is broken.

If name resolution errors crop up or timeouts occur when attempting to address a domain name, try using just the IP address (ie: yahoo.com translates to 66.94.234.13)

If you specifically see port 53 showing up in tcpdump, that may indicate a dns problem.

----------

## Hu

 *cynric wrote:*   

> 
> 
> Although the init script for iptables clears and resets policies, once it's restarted, it reads from a binary file to reconfigure iptables to the state at which you last saved it. So, stopping and starting will not give you a fresh slate if your last save state is broken.
> 
> 

 

The saved file is text, not binary.  Parts of it are similar in appearance to the arguments given to iptables, and can be safely edited by hand if you know what you are doing.  For the benefit of new readers: the location of the saved file is set by the variable IPTABLES_SAVE, which is usually defined in /etc/conf.d/iptables.

----------

