Rule not being matched

[Northy]

I have a strange issue where the firewall does not match traffic to spefic rule and ultimately drops the traffic on the cleanup rule. 

firewall cluster in HA using VRRP

The rule i expect it to match on is rule 67 whereas cleanup is rule 112 in this policy

The rule looks similar to;

Object_group_src -> Object_group_Dst on TCP/3389 permit and place into vpn community

within the object_group_src there are approx 14 different subnets. all subnets within this group have no issues except for the subnet 10.10.25.0/24, which for some reason bypasses the rule and goes straight to cleanup.

I have checked and quadruple checked the src, dst and service and all should match the rule as intended but the logs still show dropped against the cleanup rule. 

I have done a packet capture and confirmed the traffic matches the rule, i have installed policy and database. 

I have attempted to create a specific rule to match the traffic to no avail it still goes straight to cleanup. 

now i am at a loss

The only things i can see that i can try now is failover the cluster to see if this is just a problem isolated to the single member and or disable secureXL to see if this is misbehaving with the traffic in someway. 

any advice would be appreciated. 

Using R80.10 if that matters.

[Tommy_Forrest]

There any NATing going on for this tunnel?

[JozkoMrkvicka]

I bet that this is a VPN issue.

Both Source (10.10.25.0/24) and Destination are in correct VPN encryption domains? Does VPN in the rule match correct VPN community ?

[Northy]

There is NATing, the nat essentially matches traffic using the same objects as in the access rule and hides the source behind an address that is permitted on the VPN. The NAT is fully functional as the other subnets in the object are perfectly fine with no issues.

The Rule fully matches the VPN community and no issues are seen with the VPN being established or used. As mentioned it works for every other subnet except for this one subnet

[PhoneBoy]

The question is which IP does the gateway see: the object IP or the NAT IP?

[Northy]

The gateway sees traffic from the untranslated source address for example 10.10.25.68 which is trying to reach a resource across the VPN @ 192.168.34.85 via RDP.

When the traffic is received at the gateway it should perform a NAT to hide the source behind a single address and forward across the tunnel.

The rules are configured to use the 'real ip' i.e untranslated.
Access rule
src=10.10.25.0/24 dst 192.168.34.0/24 srv=tcp/3389 VPN=target VPN community action=permit
NAT rule
orignal src=10.10.25.0/24 original dst 192.168.34.0/24 service= any
translated src=<hide ip> translated dst = original ,service= original

Hope that clarifies. As mentioned i did a fw monitor (without accell off due to being production) which i can see the traffic reaches the firewall with the correct IP's and service port.

[Vladimir · Accepted solution]

It almost seems like your peer does not include the 192.168.34.0/24 in its encryption domain.

[Timothy_Hall · Accepted solution]

That is exactly it Vladimir.  Putting the VPN community in the VPN column will not force traffic into the tunnel as interesting, only the VPN domains can do that.  @Northy please provide the VPN domain configuration for your firewall and the object representing your VPN peer.  If these are not correct it doesn't matter what your rulebase says which is why the rule is being skipped.

[Northy]

Thanks for the replies.

So i have taken a look this morning and verified that the VPN domain for the peer contained the correct network.

For sanity i also checked the local side VPN domain. well what do you know the VPN NAT hide IP is in the domain however the source subnet 10.10.25.0/24 is not in there at all.

So i have added the subnet to the VPN domain and it now works.

I wouldnt have thought that the source subnet would need to be in the VPN domain object given that it is not the subnet that would be traversing the VPN the Hide IP would be.

Thanks for your all your suggestions sometimes simply talking through a problem helps to get you back on track, Thanks Vladimir and Tim for your suggestions.