Watchguard Firewall with two interfaces not allowing VOIP phone to connect

I assume there needs to be a policy in place to get the two to talk.

This sounds about right. Does other traffic flow between the two fine?

I am unsure of what the policy needs to be.

I recommend looking at the rules between the .1 and .2 networks. Check to see what is different there. Should help narrow things down pretty fast.

What subnet do the phones get their IP addresses from? Could even be something related to DHCP. A missing  DHCP option for the .3 network  is one example.

Either ensure the phone gets a fixed address and allow traffic from that address -> PBX on all ports.

Or ensure SIP, SIPS, and relevant RTP ports are allowed. SIP = 5060 (TCP or UDP) SIPS = (5061, UDP),RTP ports should be configured in the phone and in the PBX.
so the may vary. Those are always UDP.

If I am on the .3 network I can ping the phone system on the .1 network. I cannot connect to the phone system via the browser, however. I have attached a pic of my current rule. The 1. network and the 3. network are on the same watchguard different interfaces (FYI). The 1. and the 2. network are VPN between two watchguards (FYI).

I have tried to create a rule that has the "from" the .3 interface and the "to" as a voip.SNAT as shown in the current poicy. That did not work.

If the 192.168.1.1/24 and 192.168.2.1/24 are connected via VPN tunnel and you are wanting to get the two to talk to each other, sounds like you don't need to create a policy, but rather fix your routing.

So create a static route that says:

Destination: 192.168.2.0/24
Gateway: [VPN Tunnel Address]

If you create that on the 192.168.1.1/24 Firewall, it will allow that network to communicate to 192.168.2.0/24 or at least know where to send it.

You may need to create a policy after that to actually allow 192.168.1.0/24 to talk to 192.168.2.0/24