- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Rule not being matched
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Rule not being matched
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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It almost seems like your peer does not include the 192.168.34.0/24 in its encryption domain.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There any NATing going on for this tunnel?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It almost seems like your peer does not include the 192.168.34.0/24 in its encryption domain.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.