Traffic using unintended Security Rule?

[OMatlock]

Hello folks,

We have recently installed Cisco Nexus switches and UCS system.  All of our routing has been through our PA firewall and continues to be, except for a new Management network created on the Nexus switch.  We are trying to use this management network for our vsphere hosts, etc.  We added a static route on PA to route requests to the Nexus to resolve.

The problem is that Veeam server is unable to backup VMs from the new Hosts.  As we troubleshoot, I noticed the traffic between the Veeam server and host is being identified by a Security Rule that is not related.  Wondering if that could be interferring?  I wondering why identified this way and does incomplete mean it fails?  Port 902 is Veeam related traffic...

I wondering if the unrelated security rule is identifying because of the nature of its creation, including both zones on source and destination?

I was thinking may not hit a security rule at all, since traffic should not traverse out of L3_Trust?

Config:

[BPry]

@OMatlock,

Could you provide how the unintented rule is actually configured. If I had to harbor a quess it's due to an 'app' or 'service' being set to 'any' 

[OMatlock]

Thank you BPry!

I did include a pic of the security rule that is being called out for this traffic.  Here it is again.

I've seen rules created with both zones included (instead creating two rules).  Wondering if that is causing a conflict and need to break this rule up into two?

I don't know why the rule is being triggered in the first place, which what I am trying to understand, if expected, or a problem, or related to this problem...

[BPry · Accepted solution]

@OMatlock,

Sorry about that, I glanced over the post and must have though that the first supplied rule screenshot was just an extention of the log file. 

So with the example that you supplied it's matching due to the way that the 'Permit Traffic to and from Colo' rule is built out. The logs as supplied show a source and destination of 'L3_Trust'. 

I guess I'm lost on why you aren't expecting it to hit this rule. The traffic as logged matches the rule required 'source' and 'destination' address, and since you've specified a <source/> and <destination/> member of 'any' with <application> and <service> both also being 'any' the traffic should be matching this traffic. Do you expect this to hit a rule higher in your security rulebase? If the rule you're expecting to match is beneath the provided rule that isn't going to work.  

If you don't want this to happen you'll need to break the rule out further so that intrazone traffic again hits the intrazone-default rule. You'd want to have one rule for L3_Colo to L3_Trust, and then one from L3_Trust to L3_Colo. This would cause this particualr traffic to no longer match the supplied rule. 

I'd say that this is really unrelated to your Veam issue. You should verify that Veam is actually able to reach the hosts in question and that you're able to send/receive traffic between the targets. 

[OMatlock]

Thank you BPry.

Yea, after talking to PA support, should break that rule out if wanting it to match differently.

You are right, unrelated to our Veeam issue.

We believe the issue could be that ping traffic works because it replies back through the Nexus directly to Veeam server.  But when using TCP (connection based), it needs to come back through the PA interface and routed back properly.

We are working on the best method for that.  Will update.

Updated diagram showing successful ping.  This only fails with this particular subnet.  Believe its because they share the same physical PA interface.  Other subnets that don't work fine.

[OMatlock]

Thanks @BPry

Your feedback is helpful as usual...

This makes more sense to me now.  I guess I was expecting it to use the intrazone rule, but now I can see why its not.  

This rule was created before I came.  Seems like it should be broken out into two rules.