Any/Any/Any Rule Drops Packets

Dropped ACK RST packets aren't usually a problem.

There's some other threads about it on these forums if you're interested in more details.

Why do you have an ANY/ANY/ANY rule? You're exposing your "firewalled" computers to the big bad internet.

Barry

Thanks, Barry.

It's just temporary until I get this issue figured out.

Insofar as NAT rules go, I only have a masquerading rule in place.  No DNAT or SNAT.  Is the lack of a DNAT rule the problem here?

Jason

Hi.  Here is a specific example from the Firewall / Packet Filter log that we can look at:

012:04:02-14:58:42 asg ulogd[5607]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="78:ca:39:fb:1f:34" dstmac="d0:67:e5:ee:6e:af" srcip="209.117.21.131" dstip="192.168.2.5" proto="6" length="40" tos="0x00" prec="0x00" ttl="111" srcport="443" dstport="52592" tcpflags="ACK RST" 

2012:04:02-15:12:46 asg ulogd[5607]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="78:ca:39:fb:1f:34" dstmac="d0:67:e5:ee:6e:af" srcip="209.117.21.131" dstip="192.168.2.5" proto="6" length="346" tos="0x00" prec="0x00" ttl="111" srcport="443" dstport="52648" tcpflags="ACK" 

2012:04:02-15:12:46 asg ulogd[5607]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="78:ca:39:fb:1f:34" dstmac="d0:67:e5:ee:6e:af" srcip="209.117.21.131" dstip="192.168.2.5" proto="6" length="95" tos="0x00" prec="0x00" ttl="111" srcport="443" dstport="52648" tcpflags="ACK PSH"

The 209.117.21.131 host is my company's mail server.  The ASG is at my house (where I am at the moment).  The ASG is currently sitting behind a router.  The router has a public IP address.  The ASG has an External (WAN) IP of 192.168.2.5 and the Internal (LAN) IP is 10.0.4.5 with DHCP 10.0.4.x to all of the computers in my house.

Once I have all of the kinks figured out, I will remove the router entirely and put the ASG in it's rightful place connected to the Internet on it's External interface and my home network on it's internal Internal interface.  :-)

I am confident if we can fix this issue all of the other issues will go with it.

Muchas gracias,
Jason

srcport="443" dstport="52238" tcpflags="ACK RST" 

Barry solves another one!

Cheers - Bob

I am drooling with excitement!  

What you're saying is that a new rule defined to let all incoming traffic with a source port of 443 (HTTPS) and a destination port of (some range since traffic is destined for more than 52238" with a TCP flag of "ACK RST" should pass.

Ok.  I get it!

Now, where and how do I define such a rule?  If you could provide me with a little hand holding, I would appreciate it.

Thanks!

Don't get too excited... [;)]

If you let those packets in, they won't know where to go.  And, if one does, the device that receives it won't know what to do with it.

Your problem with our answers is that you need to ask a different question.  You have a problem, and you think that you've identified the cause, but Barry explained that it's not a problem.  Please describe the real problem you're having that led to this thread.

Cheers - Bob
PS Wingman recommends How To Ask Questions The Smart Way.  I like it - it helped me.

That's some mighty fine advice.  Thank you.  And, let me say that in my short time on the forum I have been really impressed by the support and expertise by folks like yourselves.  Thank you.

Taking a step back, what I don't understand is why the Packet Filter is dropping packets when I have a any/any/any rule defined.

I have two more examples.  In this first one, it looks like astaro.org (based on the Source IP) is attempting to send something to me - and to the laptop that I am using to write this message vs. the ASG itself.

name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="d0:67:e5:ee:6e:ae" srcip="85.115.22.9" dstip="10.0.4.23" proto="6" length="481" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="53641" tcpflags="ACK PSH" 

Here is a second one, which is traffic from a server on my internal network to the ASG also on the internal side:

2012:04:02-22:09:22 asg ulogd[5607]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:19:e3:e7:ec:13" dstmac="d0:67:e5:ee:6e:ae" srcip="10.0.4.50" dstip="10.0.4.5" proto="17" length="157" tos="0x00" prec="0x00" ttl="255" srcport="61486" dstport="1900" 

Why would the ASG be dropping internal to internal traffic?

In terms of impact, the only discernible end user impact that I am seeing right now is an issue with Apple iChat's ability to sign in and/or receive messages.  This issue doesn't happen all of the time, but when it does it's repeatable.  I can solve the problem by logging into iChat using a network that's not behind the ASG and when I switch back to the ASG internal network everything still works fine.  Until some time that it's not again.

Thank you much for taking the time to help me.

Jason

Those are good questions with the goal of understanding, so I'll try to supply some tools for that...

name="Packet dropped" action="drop" fwrule="60003" outitf="eth0" srcmac="d0:67:e5:ee:6e:ae" srcip="85.115.22.9" dstip="10.0.4.23" proto="6" length="481" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="53641" tcpflags="ACK PSH"

Consulting Packetfilter Logfiles, you see that 60003 means that this packet was dropped out of the OUTPUT chain.  I only know enough about the internals of Astaro (iptables) to say that that means that Astaro already has processed this packet and the connection tracker has determined that it's supposed to go to 10.0.4.23.  I don't know why it waited to drop the packet, but ACK PSH means it's one that Barry would tell you not to worry about.

2012:04:02-22:09:22 asg ulogd[5607]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="0:19:e3:e7:ec:13" dstmac="d0:67:e5:ee:6e:ae" srcip="10.0.4.50" dstip="10.0.4.5" proto="17" length="157" tos="0x00" prec="0x00" ttl="255" srcport="61486" dstport="1900"

Consulting List of IP protocol numbers, you see that proto="17" means that this is a UDP packet.  The speedguide.net Ports Database identifies UDP 1900 as UPnP discovery.  The Astaro drops this because it doesn't speak consumereze. [;)]

an issue with Apple iChat's ability to sign in and/or receive messages. This issue doesn't happen all of the time, but when it does it's repeatable. I can solve the problem by logging into iChat using a network that's not behind the ASG and when I switch back to the ASG internal network everything still works fine.

That sounds more like something with Web Security.  Do you see anything in the Web Filtering log when that happens?  It also always pays to check the Firewall and Intrusion Prevention logs.

Cheers - Bob

Thanks, Bob, for the helpful insight and tools to help me better understand these situations better.  I will look into these in more detail and respond back with questions from here.

Happy Easter.