Default Drop Rule

Junk hitting the outside interface? Isn't that just taking regular attacks or inbound http and dropping them? 

Or am I misunderstanding something here?

I am not talking about someone hitting the interface and being dropped, I am talking about the source being the outside interface and the destination being some place outside my network.

I don't understand why a device that is technically already outside the firewall would be showing up in the packet filter log. If it doesn't have to pass the firewall, how is it being blocked?

Any update on your original question? I too see the following:

16:01:28 Default DROP TCP 192.168.11.100:53373 → 209.85.139.147:80 [ACKFIN] len=40 ttl=64 tos=0x00

16:01:28 Default DROP TCP 192.168.11.100:54332 → 209.85.139.99:80 [ACKFIN ] len=40 ttl=64 tos=0x00

192.168.11.100 being my external address. At times 192.168.11.200 is quite persistant with several entries within a few seconds.

I also see:
16:07:55 Default DROP UDP 192.168.2.199:138 → 192.168.2.255:138 len=229 ttl=128 tos=0x00 srcmac=xx:xx:xx:xx:xx:7a dstmac=xx:xx:xx:xx:xx:bf

srcmac=xx:xx:xx:xx:xx:7a being a host on the internal network
dstmac=xx:xx:xx:xx:xx:bf being Astaro's internal nic

I am quite new to Astaro so I would appreciate any help offered.

209.85.139.147 & 209.85.139.99 are both google ip addresses, so why would my Astaro box be contacting google from it's external address?

No, I never did get any explanition to this.  

I don't really think that they know why it's doing that, which explains the "No answer".

I wasn't aware that the ASL box would connect to anywhere other than the up-2-date site, yet acording to my logs my outside interface is initiating connections, and the default drop rule is blocking them.

It's been so long since I asked that I just forgot about it, which was probably their plan.

The system I origionally reported it on has since been re-loaded with version 6.*** due to issues "I" have with the way the HTTP proxy profiles.  I still run it at home just so I can keep up with the latest updates for v7, but have yet to see any incentive to update our school's firewall to v7.  

This "phantom" drop is the least of my issues with v7 at the moment, and to be honest, had forgotten all about it.

Hi

I doubt it's your ASG guys, it is probably an internal node with a MASQ NAT, so it looks like it is coming from your ASG.

Can you test by isolating your internal network and see if it is still doing it.

There is definitely something wrong with Astaro's rc.firewall scripts. This traffic is generated by the HTTP proxy. It looks like it is dropping requests to google servers. I too have seen issues were the default drop rule is dropping both port 80 and port 6000 (Content Filter Database Lookups) on the external interface. This could have to do with the stringing up of multiple proxies (Squid and HTTP Proxy). I have setup a support case with this and am yet to here from Astaro about this issue as well as several others.

So sorry, but when the Packet Filter default drop rule drops packets and lists the source IP as the external IP of my ASG box, I have to "assume" that it knows what it is talking about.

If it really isn't my ASG box then this is just another part of v7 reporting that's broken. Every once in a while it would be nice to look at one of the reports and have some faith that it's correct.

Hi,

I am seeing entries in my packet filter logs where the "Default Drop Rule" is dropping packets from the outside interface of my ASG box to the outside world.
 
19:45:29 Default DROP TCP 67.78.124.162 : 44550 
 → 204.0.3.64 : 80 
 [ACKFIN ] len=52 ttl=64 tos=0x00 
 
 
Any ideas/reason why the box its self would be connecting to this site?

The connection is probably either from a client that is connecting through the firewall (and gets masqueraded on the outside interface) or he is connecting through the proxy on the ASG.



Nevertheless, dropped ACK-FIN packets are usually observed on TCP connections where the shutdown of the connection takes to long (IP conntrack
requires the FIN packet to arrives in 60 seconds after the last packet). 


So if the delay between the last packets are >60s, the kernel removes the connection tracking entry, and drops the packet as he has no connection where this packets belongs to.

The same happens if the connection was unexpected shutdown by a RST packet from the other side.


In most cases this is a condition that can be ignored - if that is not the case, i would start looking what's causing this delay.


Cheers,


Sven.

And how would I know if that were the case?  Is it not possible to code the packet filter reporting  in such a way that it gave an accurate descriptin of what is going on?