1 of 1 people found this helpful
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.