I have to confess that this is an area which I'm still very sketchy on and as I shall be installing a brand new v8 appliance tomorrow, I thought I'd just double-check exactly what needs to be done.
In response to a query in another thread, Sam Liedl, said the following:-
"The command to turn on intrazone packet forwarding at version 8 is:
$> cf agent modify name='TCP/UDP Packet Filter' intrazone_forwarding=yes
I just wrote a KB for it, but the text above is all that's in the KB article."
I then queried whether it was still necessary to create the accompanying rule, as per v7, and was told that it was.
In the past 24 hours we've just upgraded one of our customer's 7.0.1.02 boxes to 8.1.1 and I can see the intrazone_forwarding setting has been enabled against the "TCP/UDP Packet Filter" agent, but the "Intraburb forwarding" rule (as it was called in v7) now uses the <Any> service instead of the 'intraburb' packet filter created at the time of the v7 installation.
So, on the brand new box I shall be working on tomorrow should it simply be a case of
If someone would be kind enough to confirm, I'll sleep a lot easier tonight.
If it isn't correct, please advise me on what I need to do - whatever it is, it needs to allow all hosts on all internal subnets to be able to see each other for all services. I understand, and agree, with Sam's comment in another discussion thread that "there are very few situations where you would want to bounce traffic off a firewall's interface", but as this customer is 3-4 weeks away from being in a position to install inter-subnet routers, yet insist on the new Firewall being installed tomorrow, my hands are tied.
Those two steps will accomplish what you need.
>If someone would be kind enough to confirm, I'll sleep a lot easier tonight.
I really would not expect it to be a problem at all, hopefully you get some sleep. If anything does come up tomorrow, we have support 24/7, so feel free to call in.
Thanks Matt - much appreciated.
Though you didn't spot my deliberate mistake - it should be intrazone_forwarding, of course, rather than intrazone-forwarding.
I have a copy of the customer's grant letter with me and have the tech support number in my phone, so I will call in if I have any specific problems. Though this is the only one I can think of. I had the customer's box acting as my own personal Firewall for 48 hours before I shipped it out to them so everything else should work - touch wood.
Things didn't quite go to plan, but between us my colleague an I have managed to get things working in the way we expected them to, and some of this infomation may prove to be useful - I'd even go as far as suggesting that it is added to the KB article.
Though I knew this in advance, I think KB70885 would benefit from including the fact that you have to create a rule in addition to the cf agent modify.......intrazone_forwarding=yes command.
However, creating the rule in the manner discussed above doesn't necessarily make everything work.
With the firewall appliance installed and running, the first major headache I had to overcome was getting the 3 configured IPSec tunnels to work. I had remote access to one of the remote sites and therefore had the benefit of being able to see what the version 7 appliance sitting there had to say about matters. What was really confusing was the fact that it believed the tunnel to be alive and well and even more so, I could sit on that Firewall's CLI and ping back to devices on the network where I was physically sitting at the time. During this time I was running a TCP dump on the internal interface of my new Firewall and seeing....nothing. (cue head-scratching). I tried calling support, but after 20 mins waiting to get through I decided to carry on with my own tests.
Eventually, disabling the "intrazone routing" rule I have created resulted in all 3 IPSec tunnels springing into life, complete with evidence of bi-directional traffic in each case. But as this was with no "intrazone routing" rule in place, I had to do something to try and address this. In the end, I came up with the idea of defining subnet objects for each internal subnet, putting these subnets into a netgroup and then using this netgroup in the rule so that it read:-
From internal/LondonSubnets, To internal/LondonSubnets, Application=<Any>
This morning, the customer reported issues which had not arisen on Saturday and both appeared to be related to the "intrazone routing" rule.
The first tweak, was an oversight on my part, changing the NAT value from "<localhost>" to "<None>" - something which was confirmed by checking the equivalent rule on one of our customer's v7 appliances.
The second was a bit more substantial. With the customer reporting that hosts on one subnet were still unable to access hosts on another (even though the Firewall itself could see both with no problem), inspecting real-time audit of the "intrazone routing" rule showed each audit entry said "Dropped a TCP packet with no matching session" and was issuing an RST to each request. My colleague overcame this by creating a duplicate of the Generic application defense called "connection settings", disabling Stateful Inspection and applying this defense to the defense group being used by this rule (which itself was a duplicate of the "connection settings" defense group).
It was only after this last change was applied that everything started to work normally.
Nice to meet you.
My test is the same as your step and it can resolve "Internal to Internal IntraZone Traffic". But I have another question....
How to create Internal to Internal ICMP Access Rule?
I've tried source zone=internal, destination zone=internal, application=ICMP, action=Allow and the rule is placed before all rules,
It worked not normal because it was sometime good and sometime bad.
If you create your Intrazone rule in the same way I have (Application=All), you shouldn't have to create one for ICMP.
At the end of the day, the intrazone forwarding is needed to allow subnets in the same zone to see each other - with the machines on each using the Firewall as the default gateway - so it isn't as if you need to restrict your access.
If you did then you would connect these subnets to different interfaces on the Firewall and assign them to different zones.