Traffic using unintended Security Rule?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Traffic using unintended Security Rule?

L4 Transporter

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...

pasecurityrule3.jpg

 

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?

pasecurityrule2.jpg

 

Config:

pasecurityrule.jpg

 

1 accepted solution

Accepted Solutions

@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. 

 

View solution in original post

5 REPLIES 5

Cyber Elite
Cyber Elite

@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' 

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?

 

pasecurityrule2.jpg

 

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...

@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. 

 

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.

 

pasecurityrule4.jpg

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.  

 

 

  • 1 accepted solution
  • 3280 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!