How can I trace a broken port forward?

Hi All,

I have a customer with an embedded Linux device that the
vendor wants to communicate with. It goes through my
iptables firewall.

I have run "iptables -- list" against two other tables
that do the same thing in my firewall. Everything
matches, except the ports and IP's are different. For
instance (sorry for all the redacting):

# service iptables status | grep -i xxxx
3 DNAT tcp -- 0.0.0.0/0 71.aaa.bbb.ccc tcp
spts:1024:65535 dpt:xxxx flags:0x17/0x02 to:192.168.255.189
5 ACCEPT tcp -- 0.0.0.0/0 192.168.255.189 tcp
spts:1024:65535 dpt:xxxx flags:0x17/0x02
9 ACCEPT tcp -- 0.0.0.0/0 71.aaa.bbb.ccc tcp
spts:1024:65535 dpt:xxxx flags:0x17/0x02 state NEW,ESTABLISHED
4 ACCEPT tcp -- 71.aaa.bbb.ccc 0.0.0.0/0 tcp
spt:xxxx dpts:1024:65535 state RELATED,ESTABLISHED


# service iptables status | grep -i yyyy
5 DNAT udp -- 0.0.0.0/0 71.aaa.bbb.ccc udp
spts:1024:65535 dpt:yyyy to:192.168.255.42
7 ACCEPT udp -- 0.0.0.0/0 192.168.255.42 udp
spts:1024:65535 dpt:yyyy
11 ACCEPT udp -- 0.0.0.0/0 71.aaa.bbb.ccc udp
dpt:yyyy state NEW,ESTABLISHED
6 ACCEPT udp -- 71.aaa.bbb.ccc 0.0.0.0/0 udp
spt:yyyy dpts:1024:65535 state RELATED,ESTABLISHED


The only difference is tcp vs udp. I think the problem is the
vendor's equipment.

Problem: how do I go about proving it?

Many thank,
-T

Todd wrote:
> Hi All,
>
> I have a customer with an embedded Linux device that the
> vendor wants to communicate with. It goes through my
> iptables firewall.

<snip iptables extract>
>
> The only difference is tcp vs udp. I think the problem is the
> vendor's equipment.
>
> Problem: how do I go about proving it?
>

Do a tcpdump capture on both interfaces for the IP addresses involved.
Alternatively, depending on how heavily loaded the firewall is, and how
complex the ruleset, log all blocked traffic. But then the vendor can
still claim 'you forgot one -j LOG'.

-j

On 03/27/2011 11:27 PM, jack wrote:
> Todd wrote:
>> Hi All,
>>
>> I have a customer with an embedded Linux device that the
>> vendor wants to communicate with. It goes through my
>> iptables firewall.
>
> <snip iptables extract>
>>
>> The only difference is tcp vs udp. I think the problem is the
>> vendor's equipment.
>>
>> Problem: how do I go about proving it?
>>
>
> Do a tcpdump capture on both interfaces for the IP addresses involved.
> Alternatively, depending on how heavily loaded the firewall is, and how
> complex the ruleset, log all blocked traffic. But then the vendor can
> still claim 'you forgot one -j LOG'.
>
> -j

Thank you!

I do log "everything else". Does not show up. All sorts of other
crap does though.l

tcpdump does not seem to hard to use (man tcpdump). I think I
will just use either the device's IP or the port that is being
forwarded. Do you have tips on using it?

-T

On 03/28/2011 11:02 AM, Todd wrote:
> On 03/27/2011 11:27 PM, jack wrote:

>> Do a tcpdump capture on both interfaces for the IP addresses involved.
>> Alternatively, depending on how heavily loaded the firewall is, and how
>> complex the ruleset, log all blocked traffic. But then the vendor can
>> still claim 'you forgot one -j LOG'.
>>
>> -j
>
> Thank you!
>
> I do log "everything else". Does not show up. All sorts of other
> crap does though.l
>
> tcpdump does not seem to hard to use (man tcpdump). I think I
> will just use either the device's IP or the port that is being
> forwarded. Do you have tips on using it?
>
> -T

Hi Jack,

I have what I need. I love this tcpdump! Thank you so much.

-T

On 03/28/2011 11:24 AM, Todd wrote:
> On 03/28/2011 11:02 AM, Todd wrote:
>> On 03/27/2011 11:27 PM, jack wrote:

> Hi Jack,
>
> I have what I need. I love this tcpdump! Thank you so much.
>
> -T

And, I fixed it. The devices did not have their default
router configured. Rasberries!

Bad: GATEIPAddress=0.0.0.0
good: GATEIPAddress=192.168.255.10

Yipee! It took me about 7 hours to figure this out,
but I finally did. And, the default router was not in the
vendors configuration directions!

Thank you Jack. I could not have figured it out without you!

Now, I will do my best to stop strutting. Maybe in an hour
or so!

-T
P.s. Yipee!

Todd wrote:
> On 03/28/2011 11:24 AM, Todd wrote:
>> On 03/28/2011 11:02 AM, Todd wrote:
>>> On 03/27/2011 11:27 PM, jack wrote:
>
>> Hi Jack,
>>
>> I have what I need. I love this tcpdump! Thank you so much.
>>
>> -T
>
> And, I fixed it. The devices did not have their default
> router configured. Rasberries!
>
> Bad: GATEIPAddress=0.0.0.0
> good: GATEIPAddress=192.168.255.10
>
> Yipee! It took me about 7 hours to figure this out,
> but I finally did. And, the default router was not in the
> vendors configuration directions!
>
> Thank you Jack. I could not have figured it out without you!
>
> Now, I will do my best to stop strutting. Maybe in an hour
> or so!
>
> -T
> P.s. Yipee!

Glad you sorted it out, unknown devices and finger-pointing can both be
a pain. tcpdump can be a great help to see what is happening on the
wire. What I often do is take a capture using tcpdump -s0 -w
/tmp/somefile.pcap, copy the pcap files to my own machine, and use
wireshark to go through the capture file.

-j

On 28.03.2011 07:43, Todd wrote:
> Hi All,
>
> I have a customer with an embedded Linux device that the
> vendor wants to communicate with. It goes through my
> iptables firewall.
>
> I have run "iptables -- list" against two other tables
> that do the same thing in my firewall.
[...]
I bet you mean 'chains'.

>
> # service iptables status | grep -i xxxx
> 3 DNAT tcp -- 0.0.0.0/0 71.aaa.bbb.ccc tcp spts:1024:65535 dpt:xxxx
> flags:0x17/0x02 to:192.168.255.189

What's that tcp flags stuff doing there?
The nat table only sees packets of state NEW. And will only map on SYN
packets automatically.

> 5 ACCEPT tcp -- 0.0.0.0/0 192.168.255.189 tcp spts:1024:65535 dpt:xxxx
> flags:0x17/0x02
> 9 ACCEPT tcp -- 0.0.0.0/0 71.aaa.bbb.ccc tcp spts:1024:65535 dpt:xxxx
> flags:0x17/0x02 state NEW,ESTABLISHED

Again tcp flags. If i read it correctly, you specify SYN packets. So why
state ESTABLISHED? That cannot match. Better sort out bad tcp packets in
a dedicated chain before. With a rule like:
-A BAD_TCP_PACKETS -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m
state --state NEW -j DROP

Design suggestions:

- top rule: allow state ESTABLISHED(,RELATED)
- sort out bad tcp packets
- allow by state new in dedicated chain:
-A NEW_CONNECTIONS --your_match_conditions ...
...
--state NEW -j NEW_CONNECTIONS

[...]

Best regards

Mart