I have to confess I am still finding it difficult to understand, configure, and implement intrazone (formerly intraburb) forwarding successfully on MFE v8.
Why the very easy, single checkbox, setting in v6 was ever removed is a complete mystery to me.
Anyway, the basic scenario I am working with is that MFE has a number of static routes configured and I wish for any client machine using MFE as it's default gateway to be able to benefit from these routes. As mentioned in v6 and earlier, all that was required was to check the "Intra-burb packet forwarding" setting against the internal burb entry and that was that.
In v7 it was necessary to create a custom packet filter service and use this to enable intraburb forwarding and then create a second service which was then used in an access rule.
As far as v8 is concerned, KB article KB70885 provides us with the CLI command
cf agent modify name='TCP/UDP Packet Filter' intrazone_forwarding=yes
but then goes on to say nothing more than Intrazone forwarding now works for TCP/UDP filters. Previous discussions threads have indicated that in v8 it is still necessary to create the access rule (along the same lines as v7) but necessarily how that rule should be constructed.
I've tried source zone=internal, destination zone=internal, application=<Any>, action=Allow and if the rule is placed anywhere before the Administration group I find myself prompty kicked-out of the Admin Console. If placed after the Adminstration rule group it doesn't stop you from accessing the Firewall, but other things such as site-to-site VPNs then stop working.
So, rather than continue to speculate or experiment, as I did when I last came up against this hurdle (see thread from June 2011 on the same subject), do any of the McAfee guys in this community have a template for how this rule should be constructed to allow the Firewall serve its static routes to client machines on the internal zone and where best to place this rule in the rule set to stop it from causing all maner of problems with other services.
You are absolutely correct, you have outlined the differences between version 6, 7 and 8 for the intra-burb or intra-zone forwarding option.
I can confirm that you are creating your rule correctly after turning the intrazone_forwarding option on. As you have noticed, if you place this "intra-zone" rule above your Admin Console rule, the "intra-zone" rule picks up your Admin Console traffic and you are not able to connect. Definetly recommend putting your Admin Console rule at the top (ideally just place the "Administration" rule group at the top if possible).
I have not heard of the second scenario where the VPNs stopped working, though, if you think about it logically, if the ISAKMP port 500 or port 4500 traffic hits your intra-zone rule instead of the ISAKMP rule, I can see why it would fail. Have you tried to put the ISAKMP rule at the top as well (or at least above the intra-zone rule)?
To alleviate any issues, I guess the best bet is to put the intra-zone rule at the bottom of your policy, just above the Deny All,
hope this helps.
I can confirm that you are creating your rule correctly after turning the intrazone_forwarding option on. As you have noticed, if you place this "intra-zone" rule above your Admin Console rule, the "intra-zone" rule picks up your Admin Console traffic and you are not able to connect. Definetly recommend putting your Admin Console rule at the top (ideally just place the "Administration" rule group at the top if possible). I have not heard of the second scenario where the VPNs stopped working, though, if you think about it logically, if the ISAKMP port 500 or port 4500 traffic hits your intra-zone rule instead of the ISAKMP rule, I can see why it would fail.
That's why I'd dearly like to see a screenshot or copy of an intrazone forwarding rule in the way that you would create it, if possible. Becuase in the three of four occasions I've needed to create an rule of this nature, I've found that I've needed to do something different to make sure that it doesn't conflict with something else in the ruleset..
As you've indicated, it must be positioned after the Admin rules, otherwise you can't log into the GUI. We've also established that you need to assign an application defense group where the "Generic" app defense has Stateful Inspection switched off (basically, we duplicate the "connection settings" app defesnse group, call it something like "intrazone" and disable stateful inspection. Plus as I've mentioned above, I've found that if you leave the source and destination endpoint values as "<Any>", it stops IPSec VPNs from working. So, I've resorted to creating a netgroup object containing subnet objects belonging to all of 'routeable' subnets and using these as the endpoint values instead of <Any>.
This basically is what I am now using:-
If we can agree that it is correct (or come to an agreement of what is correct) then I would request that the v8 Intrazone KB article be modified to include an example of an appropriate Intrazone rule which may hopefully make this KB article a bit more useful.
It's been awhile since I have looked at this.
From reading this again, it seems the concern is that the intrazone forwarding rule, placed above an administration rule, conflicts with it and prevents the administration rule from functioning. There really is no magic way of configuring a rule like this. The key is in the ordering of the rules. If you put an "<any>" service rule with source zone of any and dest zone of any, that rule will "grab" your Administration traffic and not be able to process it properly because it is simply a filter rule. To prevent this rule for conflicting, put it below your administration rule, or somehow configure the rule so that it does not "grab" your Administration traffic. It appears that Phil has locked his rule down to subnets instead of any to prevent the administration traffic from hitting the intrazone rule.
In this instance, the intrazone rule is located after the administration rules. The apparent need to lock the intrazone rule down by including the subnets in the source and destination endpoint sections was because without this restriction the customer was left in a situation where none of his site-to-site VPNs worked.
The intrazone rule was a late edition to the ruleset, so we had already tested the VPNs. When it became apparent that the intrazone rule was needed, I created it and placed it immediately before Deny_All (which is where I'd normally put the same rule in v7). We then tested to make sure that an internal client machine, using the Firewall as its default gateway, could see all of the other subnets - and it could. But, it then became apparent that traffic was unable to pass across the VPNs (despite the tunnels themselves having a status of "active"). I disabled the intrazone rule and it was again possible to send traffic over the VPNs. Knowing that the customer needed both functions (VPN & intrazone routing) I then modified the intrazone rule purely as an experiment..
This resulted in both intrazone traffic and VPN traffic working, but I never fully understood why.
With few exceptions all of the site-to-site tunnels I set up for my customers terminate on the internal zone.
I've just logged into this customer's appliance an can confirm that it is indeed the case here. Two tunnels, both terminating on the internal zone.
From a security standpoint it was always advised to terminate VPN tunnels on an virtual zone in order to allow inspection and enforce policies to remote users. I'm sure you know that Phil, can you tell me why your company decided to terminate tunnels on the inside zone?