Alrighty, I gotta imagine that there are a bunch of other Cisco partners out there wondering about this same exact thing, so I am going to do my best to explain the reasoning behind why the Cisco document regarding integrating the UC500 with an external firewall is documented the way it is.
Second, I wan't the firewall LAN to have both the same subnet and VLAN as the UC, namely, 192.168.10.0 and 10.1.1.0. (VLAN 100).
If your UC540 is connected to your firewall via the WAN port on the UC540, you won't be able to achieve this as the UC540 (or any router) will not allow you to have the same subnet assigned to different layer 3 interfaces on the box.
Third, I want the DATA VLAN to go out the firewall WAN and want the VOICE VLAN to go out the UC WAN. Both the Firewall and UC WANs will have public static IP's.
Are you trying to do this because you have different providers for your voice and data traffic? The only way I can think of addressing this issue would be to have the firewall assigned to your data VLAN and then have that set as the default gateway. This could cause issues if you are using any CTI apps that require the data VLAN to communicate with the voice VLAN or if you have any clients on the data VLAN that need to access CUE from their workstation. You could add static routes on your workstations to work around this but that is a really sloppy way to go about this.
I'm not sure why the WAN port on the UC is used at all if there is an existing firewall in place. Why the extra routing like in the doc? Why isn't the SA (in this example) have the same data and voice network addresses and connected to the expansion port of the UC, and all traffic would go out the firewall using the voice and data gateways of the firewall -- say, 192.168.10.3 and 10.1.1.3. Unless there is some sort of functionality loss like SSLVPN for the 525 phone. That said, I find it odd that it's not mentioned. I'm surprised that the doc doesn't show the UC BESIDE the firewall as well in the scernario. That is, why does the UC need to be a router in addition to the firewall?
Okay, so Cisco designed the UC500 to be the core switch/router for the network it is being deployed in. And this makes sense considering it is essentially a slimmed down ISR bundled with telephony features and licensing. Keep in mind that this device has 3 VLANS/subnets out of the box and potentially more depending on how you configure it. If we go and start changing the default gateway on any of our VLANS to use any other device aside from the UC500, it will make accessing the other VLANS that terminate on the UC500 a real pain in the ass. This is why the firewall integration document only describes scenarios in which the firewall is in line (be it behind or in front) with the UC500. Also, keep in mind that the UC500 has to function as a router, but does not have to use NAT or any firewall features.
My other question is how do I route the WAN traffic on the voice VLAN out the WAN interface on the UC? So I might have something like ip route 0.0.0.0 0.0.0.0 192.168.10.3 (Internet traffic goes out the firewall default gateway), but that takes care of both the data and voice VLANs. So, I know that the default gateway of the data LAN would be something like 192.168.10.3 (on the firewall) and the voice VLAN 10.1.1.1 (on the UC), but I'm still not seeing how the voice VLAN knows that it's next hop should be the WAN interface of the UC since the above ip route says otherwise. And then there is the CLI for the test. Not sure how to do that.
If you were to assign your firewall to the data VLAN on the UC540 and have that set as the default gateway for that VLAN then the default route on the UC540 would not impact the traffic as the firewall would be responsible for the default route. The default route in the UC540 could then be used for all of your voice traffic.
In my experience, integrating the UC500 into an existing network is by far the most challenging aspect of the deployment process. This is not because of technical challenges but mostly due to resistance from other IT vendors involved in the project - It makes them nervous having to funnel all of the traffic through a box that they did not recommend in the first place. This is why planning of the deployment is so crucial.
I hope this information has helped. Please let me know if you have any more questions.
Thanks,
Cole
