# [SOLVED] Debugging iptables

## nixscripter

I have a three interface box:

eth0 - outside world

eth1 - intranet one

eth2 - intranet two

Intranet one works fine. I'm using it to type this post. However, intranet two has a problem: I cannot ping any clients connected to it.

On the server:

```

# ifconfig eth2 

eth2      Link encap:Ethernet  HWaddr 00:04:76:34:b3:26  

          inet addr:192.168.5.1  Bcast:192.168.5.255  Mask:255.255.255.0

          inet6 addr: fe80::204:76ff:fe34:b326/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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

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

          collisions:0 txqueuelen:1000 

          RX bytes:144174 (140.7 KiB)  TX bytes:6532 (6.3 KiB)

          Interrupt:21 Base address:0xa000 

# ping -c 1 192.168.5.1 

PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.

64 bytes from 192.168.5.1: icmp_seq=1 ttl=64 time=0.061 ms

--- 192.168.5.1 ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.061/0.061/0.061/0.000 ms

# ping -c 1 192.168.5.3

PING 192.168.5.3 (192.168.5.3) 56(84) bytes of data.

ping: sendmsg: Operation not permitted

--- 192.168.5.3 ping statistics ---

1 packets transmitted, 0 received, 100% packet loss, time 0ms

```

In fact, I cannot send any data on that interface at all that the client can see. When I ping it from the client, I can see the pings with tcpdump:

```

# tcpdump -i eth2

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes

13:17:20.920676 arp who-has 192.168.5.1 tell 192.168.5.3

13:17:20.920704 arp reply 192.168.5.1 is-at 00:04:76:34:b3:26 (oui Unknown)

13:17:20.923511 IP 192.168.5.3 > 192.168.5.1: ICMP echo request, id 19009, seq 1, length 64

```

But the server cannot answer.

I also cannot connect to any services on the router, as the syn-ack packets are not sent out:

```

13:18:52.259933 IP 192.168.5.3.33068 > 192.168.5.1.ssh: S 3945225285:3945225285(0) win 5840 <mss 1460,sackOK,timestamp 38543014 0,nop,wscale 6>

13:19:00.321592 IP 192.168.5.3.33069 > 192.168.5.1.ssh: S 4071199555:4071199555(0) win 5840 <mss 1460,sackOK,timestamp 38545030 0,nop,wscale 6>

13:19:00.321592 IP 192.168.5.3.33069 > 192.168.5.1.ssh: S 4071199555:4071199555(0) win 5840 <mss 1460,sackOK,timestamp 38545030 0,nop,wscale 6>

```

By now, you are thinking "it's iptables." I''m thinking that too. In fact, Google says that ping error message can be cause by iptables.

But where is the problem? These rules work fine for clients on intranet one, so why not two?

```

# Generated by iptables-save v1.4.2 on Wed Dec 15 13:27:31 2010

*mangle

:PREROUTING ACCEPT [617207854:808172308417]

:INPUT ACCEPT [557709605:760898304269]

:FORWARD ACCEPT [58907867:47044203539]

:OUTPUT ACCEPT [285338908:151305901877]

:POSTROUTING ACCEPT [344246742:198350100863]

COMMIT

# Completed on Wed Dec 15 13:27:31 2010

# Generated by iptables-save v1.4.2 on Wed Dec 15 13:27:31 2010

*filter

:INPUT DROP [73:24892]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [1236:164114]

[2:168] -A INPUT -i lo -j ACCEPT 

[1966:162163] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

[89:6153] -A INPUT -i eth1 -j ACCEPT 

[26:1696] -A INPUT -i eth2 -j ACCEPT 

[1897:444013] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 

[82:4924] -A FORWARD -i eth1 -j ACCEPT 

[0:0] -A FORWARD -i eth2 -j ACCEPT 

[0:0] -A FORWARD -s 192.168.0.0/16 -i eth0 -j ACCEPT 

[0:0] -A FORWARD -d 192.168.0.0/16 -j ACCEPT 

COMMIT

# Completed on Wed Dec 15 13:27:31 2010

# Generated by iptables-save v1.4.2 on Wed Dec 15 13:27:31 2010

*nat

:PREROUTING ACCEPT [5294160:1126994959]

:OUTPUT ACCEPT [548665:36628810]

:POSTROUTING ACCEPT [151643:15968463]

[851839:53971640] -A POSTROUTING -o eth0 -j MASQUERADE 

COMMIT

# Completed on Wed Dec 15 13:27:31 2010

# Generated by iptables-save v1.4.2 on Wed Dec 15 13:27:31 2010

*raw

:PREROUTING ACCEPT [1601044793:2183840038794]

:OUTPUT ACCEPT [807767640:252766642296]

COMMIT

# Completed on Wed Dec 15 13:27:31 2010

```

Any help would be appreciated.Last edited by nixscripter on Tue Dec 28, 2010 8:56 pm; edited 1 time in total

----------

## truc

Two things:

Can you show the routing table on the server?

Are you sure the following are rules you want to have?

```
[0:0] -A FORWARD -s 192.168.0.0/16 -i eth0 -j ACCEPT

[0:0] -A FORWARD -d 192.168.0.0/16 -j ACCEPT 
```

----------

## gerdesj

Start from the basics until you get the hang of things!

Get your routing and forwarding sorted and then add your firewall rules one by one with testing.

Use iproute2 commands - its soooo 1990's to use ifconfig!

Try:

#ip a

#ip r

Also: #iptables -L -n -v  will be useful.

Add logging rules in your iptables.  Simply repeat the rule you are interested in just before it but  add -j LOG --log-prefix "comment" instead of -j ACCEPT or -j DENY.  Then look at #dmesg.

Cheers

Jon

----------

## Bircoph

Use -j TRACE target, this will log for you all packet path according to your rules. This helps me for very sophisticated setups.

But problem with your rules is seen without this tool. FORWARD is bi-directional chain. You should write rules not only for -i, but for -o as well. As for now you block all state NEW packets targeted to be output on eth1 or eth2.

And rule:

[0:0] -A FORWARD -s 192.168.0.0/16 -i eth0 -j ACCEPT 

may be ridiculous. You are to allow forward from private subnet incoming from outside world, unless you have not direct connection to the internet, but via that subnet.

And I assume your routing table was set up correctly.

----------

## nixscripter

Okay, now I'm back again. Let's see.

 *gerdesj wrote:*   

> 
> 
> Use iproute2 commands - its soooo 1990's to use ifconfig!
> 
> 

 

Eh, it's what I learned on. NetBSD, FreeBSD, and an ancient RedHat all did it. If iproute2 has become "the standard" (snort), then I suppose I'll have to learn it.

 *Bircoph wrote:*   

> 
> 
> But problem with your rules is seen without this tool. FORWARD is bi-directional chain. You should write rules not only for -i, but for -o as well. As for now you block all state NEW packets targeted to be output on eth1 or eth2.
> 
> 

 

Hmm. I don't see why, because doesn't:

```
[0:0] -A FORWARD -d 192.168.0.0/16 -j ACCEPT
```

match those?

Anyway, I'll try that when I get home in a day or two. I knew about LOG, but not TRACE. Thanks for the tip. LOG seemed like too much of a pain for this type of thing...

 *Quote:*   

> 
> 
> And rule:
> 
> [0:0] -A FORWARD -s 192.168.0.0/16 -i eth0 -j ACCEPT 
> ...

 

That was a typo in the rules. Thanks for catching that. It should have said eth1.

Thanks a lot, guys. I'll post again when I get back home to try it.

----------

## nixscripter

Okay, fixed it!

I decided to turn it around, and added output interface rules to the FORWARD table instead of input interface rules. When I did that, I saw the problems, and fixed it.

Thanks guys. Your suggestions helped me see it. And I'll remember TRACE.

----------

