Distributed firewall with identity firewall rules

[Charlie Silverman]

We are building out a new DFW deployment.

Most things that are based on IP or computer or some other segment-based rules work great.

The challenge we've run into is with IDFW rules.

For example, we have a rule like this tagged as "vcf_admin":

Source: AD.Group-Admin -> Destination: vcenter -> Ports: dest: 443 -> action: allow

With this rule in effect, with the final drop rule running, the connection fails.

We also have a rule tagged as "TEST_DROP":

source: MyServer -> Destination: any -> ports: any -> action: drop

This rule is essentially the default rule, just configured for my specific testing VM, while the default rule is set to allow.

When I look at the dfwpktlogs.log file on the host, I see the following:

2026-07-24T16:58:45.805Z No(13) FIREWALL-PKTLOG[2100653]: d1d3adfb INET TERM PASS 8176 OUT TCP TIMEOUT 10.0.0.5/49990->10.0.0.10/443 3/0 152/0 vcf_admin
2026-07-24T16:58:46.406Z No(13) FIREWALL-PKTLOG[2100653]: af4e255e INET match DROP 9196 IN 52 TCP 10.0.0.5/50003->10.0.0.10/443 SEW TEST_DROP
2026-07-24T16:58:46.416Z No(13) FIREWALL-PKTLOG[2100653]: af4e255e INET match DROP 9196 IN 52 TCP 10.0.0.5/50004->10.0.0.10/443 SEW TEST_DROP
2026-07-24T16:58:46.657Z No(13) FIREWALL-PKTLOG[2100653]: af4e255e INET match DROP 9196 IN 52 TCP 10.0.0.5/50005->10.0.0.10/443 SEW TEST_DROP

I understand that the return traffic is being blocked.   This only seems to be happening for IDFW rules.

If I change my drop rule to outbound only, the problem goes away.

What I'm proposing is to have a "default" rule that blocks all outbound traffic and have a second rule that blocks all inbound internet traffic.

Is there a downside to doing this?   In my testing, anyone not in the group can't reach vCenter, so that much appears to be working fine.

Is there a better way of fixing this?

[Apoorv M]

Hello Charlie,

Similar to other DFW rules IDFW rules are stateful rules.

In the dfwpktlogs.log you shared, it is evident that SYN packets are dropped on the destination. In other words your destination VM (In this case the vCenter VM based on what you said) is dropping the packet as it doesn't have any allow rules.

Let me explain it a bit further to make sense
1. The "d1d3adfb" you see in the first log line is the VIF ID of your source VM
2. The "af4e255e" you see in the 2nd/3rd/4th log line is the VIF ID of the Destination VM.
3. The first log line shows that the traffic is hitting rule ID "8196". The action is "PASS", But this log line shows that the connection is getting terminated "TERM" because it only saw one way communication as show by "3/0"
4. The 2nd/3rd/4th log lines are from the destination VM. Here the traffic is hitting Rule ID "9196" with DROP action. The "SEW" indicates that the SYN packets are getting dropped.

The reason why you are seeing this for IDFW rules is because, in this context the IDFW rules are only on the source. In other words, with the current rule config you have, you are saying if user XYZ logs into VM-A, allow him to connect to Destination (vCenter) VM from VM-A. You don't have explicity have any rule at Destination VM to allow the  incoming traffic.

Best Regards,
Apoorv Malmane


 

[Charlie Silverman]

Thank you for that.   

The next question then would be, what would the other rule look like?  I want to limit access, so having an open "allow from any" rule isn't desirable, but the user could be logging in from any machine in the network, including servers.

[Charlie Silverman]

Thank you for that.   

The next question then would be, what would the other rule look like?  I want to limit access, so having an open "allow from any" rule isn't desirable, but the user could be logging in from any machine in the network, including servers.

[Apoorv M]

In this context, The next rule should,

Source: The group of VM that the desired user/user-group can log-in to to access vCenter
Destination: Your same destination VM (In this case vCenter)
Service: Same as the Identity rule
Applied-To: Destination VM or Group containing Destination VM.          <<<<
Action: Allow
Direction: You can choose keep it Inbound only.

In short, Applied-To plays a significant role here.

In summary,
The first rule only allow specific user (say User-A) to reach the vCenter. << This is an allow rule at the source
The second rule only allows from specific sources to login into vCenter. << This is a allow rule at the destination

The recommended security posture is always default deny. If the default deny is not possible at the moment (say because other applications doesn't currently have granular DFW rules) then create a third rule with
Source: Any
Destination: vCenter VM
Service: Any
Action: Drop
This rule should be placed somewhere below the other 2 rules.

Best Regards,
Apoorv Malmane

 

 

[Charlie Silverman]

Thank you!   I knew there was something I was missing in all of this.