Missing connection logs from 6500 gateway with R80.20 Take 18

[Leon_Jaimes]

Hello,

I just set up a 6500 gateway running the R80.20 Take 18 image and Security Management Server on VMware running R80.20 M2, don't have the build handy on that.  This is a fairly sensitive environment, so I am hesitant to deploy R80.30 yet, but I have not done any technical digging into the relationship between the 6000 series and R80.30. 

I set up a handful of very basic policies, essentially the "Admin Access to Gateways", "Stealth", and then a few other rules which I have since removed and now only have those two followed by a Test rule that is any/any/accept/log to troubleshoot.

The Gatewat topology is:

• Mgmt connected to 10.20.20.0/24 as 10.20.20.100
• eth1 connected to a laptop as 10.30.30.0/24 and 10.30.30.1 on the interface and the 10.30.30.2 on laptop-A.
• eth8 connected to another laptop as 34.34.34.0/29 and 34.34.34.1 on the interface and 34.34.34.5 on the laptop-B.
• There is a static NAT on the 10.30.30.2 object with IP 34.34.34.2, and a webserver running on laptop-A.

The SMS is:

• eth1 connected to 10.20.20.0/24 as 10.20.20.200

Blades enabled are:

• Firewall
• Application Control
• URL Filtering
• Identity Awareness
• Content Awareness
• IPS
• Anti-Virus
• Anti-Bot

SIC is fine, and there are some logs from the gateway about system events, but nothing for traffic.  I can ping from Laptop-B to Laptop-A and I can see the connections with fw monitor hitting i I O o.  The webpage loads, so NAT is working.

I have been troubleshooting using sk40090 and none of the suggestions there have helped.

I noticed that $FWDIR/conf/log_policy.C did not match, but that was not something that I recall having to set up in the past.

I also noticed that in the General Properties of the gateway object, there is not a selection fro 6000 series, so I have that set to Other right now, but had initially tried using the settings for the 5000 series.

The topology in the gateway object matches the the way the interfaces are configured, and anti-spoofing is turned off.

I feel like I am missing something that is right in front of me.  I'm away from the project for the next week, and I just went through DemoPoint and didn't see anything that looked different than the way I have it set up.  Thought I'd put this out to you all and see what suggestions might come back.

Cheers,

Leon

[PhoneBoy]

Might try setting your track field to Detailed or Extended.
"Log" will only log Firewall-relevant information, not application control/URL filtering information.
That might generate a few extra logs.

[Leon_Jaimes]

Hi Damien,

Thank you for the suggestion, I will check that.  I didn't want to confuse the initial post, but there is a second gateway at a different site for which the logs are populating correctly, and we are not getting firewall logs at all.  For the problem gateway, we are getting the system logs showing information about when it fetches the AV and URL filtering updates for example, or policy installations.

Thanks,

Leon

[Timothy_Hall]

Make sure you did not accidentally set up your VMWare-based SMS as a gateway as well; if you did the InitialPolicy will block incoming port 257 logging connections from the gateway.  Run the command fw stat on your SMS, if it says anything other than "local host is not a firewall module", you will need to reload your SMS from scratch and ensure that you set it up as just a SMS and nothing else in the Gaia web interface post-installation wizard.

If that is not the issue, from expert mode on both the gateway and SMS run the command netstat -an | grep 257 to see what is going on with the logging connection between the two.

[Leon_Jaimes]

Hi Tim, 

Thank you for that suggestion.  I don't think that the SMS is set up as a gateway.  I didn't think that was possible with the "M" releases, but I will double-check.  It is getting some logs from the problem gateway, the logs about policy install, and AV/URL fetches.  The SMS is also getting logs from a different gateway, (not mentioned in the initial post) so I am pretty sure 257 is open.  I will continue working this with TAC, and it sounding like it reinstalling on R80.30 may be the quickest path to resolution.  I'll follow up on this when I have some better info.

Cheers,

Leon