Hey gang.
We’re setting up a unified wireless network for the students here, and to get around the issues with Nintendo and NAT we devoted a large chunk of public IP space to them.
We’re aware that this is causing issues with wifi calling on Verizon, TMo etc because it appears they initiate the SIP session inbound.
Does anybody have a handy list of IP blocks and ports? T-Mobile had a decent page but other providers just said “open up 4500 and 500” and our ISO guys don’t like that.
Thanks if someone can help.
John C. Lyden
Manager of Network Infrastructure, Infrastructure Services
Division of Information Resources & Technology, Rowan University
It’s been a minute since I’ve set this up in a corp/campus wifi scenario, but my notes for Verizon VoWiFi from the last time I did say that you need outbound udp/500 and udp/4500 IPSec protocol (IKE and ESP) permitted out the firewall. Tunnel endpoints live in 141.207.0.0/16, so hopefully that lets you scope the rule enough to please your ISO.
Devices will also need the ability to make an HTTPS request to https://spg.vzw.com/SSFGateway/e911Location/changeAddress
As well, DNS queries for the ePDG domain wo.vzwwo.com need to be permitted.
That should be all you need to get it bootstrapped.
Alex
I do dozens of VZW WiFi calls a day. My phone is behind NAT, no problem.
It’s probably 50/50 where the call starts on WiFi vs switches to WiFi after ~3 seconds from the poor VZW signal.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
Same here, one of my cell operators uses VoWiFi for their calls and SMS's.
As long as I am on wi-fi though, all calls and SMS's are sent over wi-fi.
I'm doing NAT44 + native IPv6, no special holes punched in my Mikrotik
router (the cell provider is doing WiFi Calling over IPv4).
Mark.
In our university environment, wifi calling works just fine over NAT and we have not made any inbound port exceptions in the firewall for it. The critical piece for (non-enterprise) VoIP traffic is that your firewall must not try to function as a SIP ALG, but I’m not sure that’s directly relevant to wifi calling for the major carriers.
Jason Alderfer
Director of Technology SystemsEastern Mennonite University
Also do wifi calls from Android phone on VZW behind NAT, with no issues. I do have a “network extender” which has GPS link and ethernet (also behind NAT) and it does give me 5 bars around the house (up to 70mbps ish of download over LTE).
Now, your NAT setup could possibly interefere? In my case at home I have FreeBSD with pf and NAT reflection disabled by default.
It’s been a minute since I’ve set this up in a corp/campus wifi scenario, but my notes for Verizon
VoWiFi from the last time I did say that you need outbound udp/500 and udp/4500 IPSec protocol
(IKE and ESP) permitted out the firewall. Tunnel endpoints live in 141.207.0.0/16, so hopefully that
lets you scope the rule enough to please your ISO.
Alex, thanks for the netblock info. ISO’s accepted an ‘any’ scoped to a destination of just this new network; I already land it via GRE on a separate zone from the rest of the campus network. They would, however like me to tighten it up as much as possible so the VZW netblock is a massive help.
John C. Lyden
Jason/Josh:
Thanks for the input. The issue isn’t NAT (we’re not NATing). The issue is without NAT, the Wifi Calling feature apparently chooses to initiate inbound from the carrier to the client. When NAT’d, the client recognizes the NAT and initiates on its own. Or at least that what it appears. I calls 'em like I sees 'em. Whale biologist.
If anybody has AT&T, TMo and Sprint (because I suppose we need to hold on to them as separate objects until the merger is complete) it’d be much appreciated. AT&T only lists FQDN’s here: https://www.att.com/support/article/wireless/KM1114459/ (which the Palo should [SHOULD] understand) but…paranoia I guess. Others have listed TMo as 208.54.0.0/17 and 66.94.0.0/19 as recently as 2018, and Sprint has exactly nothing.
And as I type this, someone chimed in offlist seconding 280.54.0.0/17 for TMo, so I’ll add that to my list.
Thanks again everyone!