Non logging issue

[Brinkman]

OK a little background first I'm running 4.1 on a 5050 pair in A/P.  I have a server that is trying to do 80 and 443 out to a specific address and we have some logging wierdness going on.  If we don't have a rule in place allowing the traffic it will not show up with a log entry.  If I do a packet capture I see it in the receive stage but not any other stage.  At the very least I would expect to see it in the drop stage, also, it isn't showing up in any of the logs or being sent to our syslog server.  If I have a rule in place allowing the traffic it will show up in the logs.  I have verified that my any,any,deny at the end of the ruleset is logging at both the start and end of the session and I'm still not seeing anything.  We are using the Anti-Spyware and Vulnerability protection but it currently is only setup in alert mode so it shouldn't be blocking.  Also, I have tried connecting with different ports just to make sure it wasn't a specific application issue and that has no effect.

Any help is appreciated.

Kris

[panos]

Do you have security rules for intrazones

[Brinkman]

I do not for this zone, but the connection is going from a trusted zone IP to an untrusted zone IP.

[panos]

you mean that not logging issue happens for just that 1 client ?and also to just 1 ip ?

[VinceM]

Mean no logs neither in Monitor/Traffic nor in session browser ?

no routing issue ?

v.

[Brinkman]

It will happen from that client to any IP on any port.  What it looks like is if that client sends out a SYN and a SYN-ACK never comes back the firewall doesn't log the connection, even if it passed it.  As soon as it gets the SYN-ACK back it logs it.  Am I misunderstanding the way this should work.

And I don't see anything in monitor/traffic nor the session browser until the SYN-ACK is received back, if I never receive a SYN-ACK I never see an entry.  No there aren't any routing issues because in the beginning the one connection was not allowed at the distant end but as soon as they put the access in it came up fine and starting working.

[panos]

you have to see incomplete logs even you send syn.

Can you try to delete all logs and restrart log server ?

debug software restart log-receiver

[Brinkman]

OK I tried that and no change.

[jcostello]

The implicit deny rule on a PAN will not generate log entries.

You would need to have an explicit deny rule with logging enabled to see the traffic that is denied.

[Brinkman]

Yep that's what I have and it's set to log at the start and end of the session.

[panos]

you should better open a case.

should take 2 captures

1- at client interface

2- at Paloalto interface

filter and look if client sends and paloalto receives support will investigate that.

[jcostello]

The deny all logging can put a strain on the log-receiver (in my experience)

From the CLI try the following command

debug log-receiver statistics

look for entries under Logs discarded (queue full)

[Brinkman]

I've already verified that the client is sending the packet and I know PA is receiving it.  Is this just a case of how the underlying system works where it won't create any log entry until the 3 way handshake is complete.

[Brinkman]

There aren't any that showed they were discarded.  The rate is 112/sec.

[jcostello]

With the settings of start and end on the logging of all traffic on that deny rule, you will fill the logging queue on the box and it will not be able to process all of the logs.

With something that is denied, it won't wait for the three way handshake to log an entry if logging functioning correctly