Issues with Battle.Net Services

Try turning on the SIP helper and see if that helps.

I've tried a few different combinations of that in the past but it doesn't seem to help.
Tonight I added a policy as a test with the below settings but I'm hitting the same thing.

SIP Server Networks - Any IPv4
SIP Client Networks - Internal
Expectation Mode - Any

Also, when testing the in game voice I had my firewall live log open and saw that a Blizzard IP is trying to respond to my internal client IP.
Am I missing a NAT rule?

I'm also seeing chatter on 3478 and 3479 when I connect to a new game. &3.193.117.xxx is my public IP.

At this point I'm so turned around I have no idea where the issue is :(

try adding those two ports to the SIP helper. sip helper doesn't need a NAT. Becareful with your SIP rule because you have possibly opened yourself to a flood a nuisance SIP based calls.

I don't see an option to add any ports to the SIP helper and the SIP service definition is not a group.
I tried changing SIP and SIP over SSL to be the ports I noticed above but no change.

Testing again this morning I did notice that the launcher is connecting normally again though I didn't change anything.
That part seems to be resolved but I'm still having trouble with the voice chat part.

I decided to do something a bit drastic today.

I reset my installation to factory and have been adding back features one by one (right now it's just basic functionality) until I find what's breaking this.
So far, Battle.Net is working and so is voice without the SIP helper.

Hi Brad,

Did you discover the issue with Blizzard's SIP voice services?  I'm having the same issue.  Everything works fine (launcher, etc) but I get the exact symptoms with no voice communication either inbound or outbound.  Reset and re-add services is an option but if you've got more insight I'd appreciate it.

-ME

Unfortunately I haven't figured out what caused it but I've added back almost all of my rules/policies and it's still working.

The only one I haven't added back is my NAT rules for my web server and the hairpin NAT rule to allow internal clients to hit the public IP.
However I had disabled all of those when testing before so I'm not sure what the issue is/was.

Right now I don't have anything special for BattleNet other than the below exceptions in web filtering.

^https?://([A-Za-z0-9.-]*\.)?worldofwarcraft\.com\.edgesuite\.net/
^https?://([A-Za-z0-9.-]*\.)?blizzard\.com/
^https?://([A-Za-z0-9.-]*\.)?blizzard\.vo\.llnwd\.net/
^https?://([A-Za-z0-9.-]*\.)?blizzard.com\.edgesuite\.net/
^https?://([A-Za-z0-9.-]*\.)?battle\.net/
^https?://blzddist\d-a\.akamaihd\.net/

The exception is just for AV, download size, extension blocking, and MIME type blocking.
I'm not 100% sure these are all needed anymore though, I carried them over from my old installation (it's restored in a VM).

I'm going to add back my web server rules today and see if that changes anything.

Brad

Thanks for the response.  You're actually limiting a lot more than I am... in terms of internal clients, everything is allowed through:  Internal network - using any IP Protocol - to any external destination, and I've got only one simple masq rule (internal network to external WAN).  Load Balancing is enabled with no specific pools or VOIP preferences, but that seems to have no effect regardless on the issue.  IPS is not turned on.  I don't run any internal web servers so I'm not using any special NAT rules.

I can see my internal client hitting the external voice servers in the firewall live log, but not sure I'm seeing anything coming back, and the service stays disconnected.  It's pretty much the only thing not working out of many other communications apps / games / services.  Very strange.

Thanks for the response.  You're actually limiting a lot more than I am... in terms of internal clients, everything is allowed through:  Internal network - using any IP Protocol - to any external destination, and I've got only one simple masq rule (internal network to external WAN).  Load Balancing is enabled with no specific pools or VOIP preferences, but that seems to have no effect regardless on the issue.  IPS is not turned on.  I don't run any internal web servers so I'm not using any special NAT rules.

I can see my internal client hitting the external voice servers in the firewall live log, but not sure I'm seeing anything coming back, and the service stays disconnected.  It's pretty much the only thing not working out of many other communications apps / games / services.  Very strange.

My firewall only has two rules now, a blocked hosts rule used to drop traffic for people probing, and an allow all internal to external rule, so I'm not blocking much.
I just finished adding back my two NAT rules and BattleNet still works. The only change I made to the rules was to use a group for HTTP and HTTPS instead of separate rules.

At this point I'm totally confused because my old and new configs are basically the same.
I'm wondering if there was a bug in one of the Up2Date updates and a factory reset fixes it? That's pure speculation but I have nothing else to point to.

Brad

Hmm... well, I'm somewhat jealous of your success here.  I did a factory reset and put the system in an even simpler state than before:  All internal to external, and the basic Masq any to WAN.  Nothing else enabled, and voice still doesn't work.  Turned on network visibility, and I can SIP traffic going to the Blizzard network when attempting a voice connection.  Enabling VoIP and adding the destination SIP server to any internal didn't work either. 

At this point I may have to look at NAT inbound rules explicitly redirecting that traffic to my gaming client. 

Which version are you on? I'm currently at 9.409-9.

For what it's worth I don't have any NAT rules specifically configured to send traffic to my gaming machine.

The same.  9.409-9. 

Not sure how to proceed at this point... may have to go back to PFSense.  Sophos is a better product in almost every way, but this is a long-term dealbreaker.  The inconsistency is problematic... if it wasn't working for anyone (or didn't work in repeatable firewall configurations) then that would be one thing, but having two different outcomes from the same version / configuration is tough.

I've even enabled ICMP response, as I see an ICMP packet coming back from the Blizzard SIP/Voice server, but no change. 

I *am* seeing a burst of STUN packets coming back from the Blizzard SIP server right after the request that get dropped.  Not very familiar with that protocol, so I need to do some quick research.