At times WiFi calling and sending SMS doesn't work?
-
@JohnnyBeGood said in At times WiFi calling and sending SMS doesn't work?:
What can I do?
Same here.
That is, not so long ago, the Apple devices also lauched this "Wifi calling".
Fine, I though ...
Back then, the midle of 2018 - I has a pure IPv4 home network - no pfSense @yhome. Just my ISP routeron a VDSL line.
Moving out of the house while talking : bad idea : Wifi out of range : no more blabla. had to call back, with the Wifi off.These day I have a pfSense @home with 2 straticly placed Unify APs - things are better now.
Because I'm using pfSense, I have IPv6 also using tunnel.he.net ...and their bandwidth was good, before. These days, it's less, can't blame them : it's a free service.
Our devices likes PC's, printers, Phones, TV's etc prefer using IPv6 over IPv4 : IPv4 is used if and only if IPv6 isn't available. Which means : problems are still there when using this Wifi calling.
Actually, I don't care. I'm using my 4G for calling. These days it's a one price, call - and SMS because it still exists- forever.Btw : NAT or double - why not triple ? isn't and can't be a problem. It's your phone contacting the needed servers. If it can't get out, your problem is elsewhere.
-
@Gertjan said in At times WiFi calling and sending SMS doesn't work?:
Btw : NAT or double - why not triple ? isn't and can't be a problem. It's your phone contacting the needed servers. If it can't get out, your problem is elsewhere.
NAT, even single NAT can be a problem. WiFi calling uses UDP and UDP can cause issues with NAT, as there is no "connection", as there is with TCP. This means the firewall has to figure out the destination for each incoming packet, unless there's some sort of tracking mechanism. Because of NAT, it's often necessary to use hacks like STUN servers, though I don't think that applies to WiFi calling.
-
@JKnott : very true.
Incoming UDP 'out of the sky' will get dropped : our firewall is doing what's being paid for.
Even a possible outgoing TCP connection shouldn't be considered as rock solid. We're dealing with Wifi here. people tend to think that's a connection as good as a cable one. or, surprise, it isn't. I guess our AP does its best to maintain a connection and related states, as does our Phone or any other Wifi capable devices. But ones a connection gets reset, states get reset, and the entire logical link has to be reconstructed. During that time, what gets done with incoming bits ? => they hit the wall.
All states in any device (router) on the road are ditched, everything has to be rebuild.Btw : still, I admit not knowing exactly what happens with UDP streams comming in .... our firewall should drop them if a related stream UDP doesn't exists ? UDP works also with states like TCP and so ? I have to recall my (ancient) UDP knowledge again.
Anyway, as said, I consider this wifi calling as "nice if it work - same thing if it doesn't".
It might work well will tricks like uPNP but that one was been taking in the forest in shot, no one who cares about security cried about it. -
@Gertjan said in At times WiFi calling and sending SMS doesn't work?:
I guess our AP does its best to maintain a connection and related states, as does our Phone or any other Wifi capable devices.
I expect it's more a UDP/NAT issue than WiFi. WiFi is effectively a bridge and should be transparent to whatever traffic it carries. He'll have to do some packet capture to see what's actually happening.
-
I believe Wifi-Calling initiates an IPsec connection to the carrier; going through a double-NAT would allow 1 initial connection, and then probably nothing until that first one times out (no longer registers for wifi calling).
-
@moikerz said in At times WiFi calling and sending SMS doesn't work?:
I believe Wifi-Calling initiates an IPsec connection to the carrier; going through a double-NAT would allow 1 initial connection, and then probably nothing until that first one times out (no longer registers for wifi calling).
It uses IPSec over UDP, instead of just ESP. Incidentally, Voice over LTE (VoLTE) also uses IPSec/UDP, which enables seamless transition between the WiFi and cell networks. By using UDP encapsulation, there is no problem with the changing network addresses.
-
Thanks guys for the replies!
I'm glad that its not just me having this issue. I'm using Wi-Fi calling because of very bad signal inside and without it calls get dropped. My ISP is Comcast and WAN has public IP 76.121.xxx.xx.Can someone please help me with packet capture on the LAN interface, what do you use?
I came across this video that shows packet capture with Wireshark https://youtu.be/TWqdtVJSO_8?t=505 -
Diagnostics > Packet Capture
You'll have to filter on the phone IP address, not MAC address. You can filter on MAC address by capturing everything and filtering in wireshark.
Chattanooga, Tennessee, USA
A comprehensive network diagram is worth 10,000 words and 15 conference calls.
DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
Do Not Chat For Help! NO_WAN_EGRESS(TM) -
This post is deleted! -
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
Diagnostics > Packet Capture
You'll have to filter on the phone IP address, not MAC address. You can filter on MAC address by capturing everything and filtering in wireshark.Thank you!
-
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
You'll have to filter on the phone IP address, not MAC address.
MAC filtering works fine, provided a router isn't in the way. I frequently filter on MACs. This is especially useful on IPv6, where the IP address used changes daily. Also, if using IP address, you have to determine whether IPv4 or IPv6 is used. Using the MAC captures both. I have MAC address capture filters in Wireshark, for all my devices.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
Ok, so I looked up my phone LAN IP and ran packet capture and opened it in Wireshark, but it didn't give me much info other than it was using ESP protocol (IPsec) http://prntscr.com/nt1vtx
When I checked Status > System > Logs > Firewall > Normal View I found same
Verizon IP 141.207.229.233 (233.sub-141-207-229.myvzw.com) being blocked
In UDP protocol http://prntscr.com/nt1xcu
What is interesting is both times outgoing call went through and I was able to talk.
Afterwards, I waited another ~10 minutes and tried calling again and the call would not go through!
In pfSense firewall log the time did not change and it was still showing same time when call did went through http://prntscr.com/nt1z1vMy question is how do I tell make so that pfSense does not block this is type of traffic?
Not sure what else to do. -
@JohnnyBeGood said in At times WiFi calling and sending SMS doesn't work?:
Ok, so I looked up my phone LAN IP and ran packet capture and opened it in Wireshark, but it didn't give me much info other than it was using ESP protocol (IPsec)
What you should be looking for is if there is any difference between when it works and when it fails. If you see the same coming from the phone when it fails, then the problem is likely pfSense. However, first get rid of one of the of the NATs. NAT breaks things, including UDP, so you don't want to use it more than absolutely necessary. Also, that ESP looks a bit strange. IIRC, I saw UDP, which encapsulated ESP, on my network. I'll have to look again tomorrow.
I have WiFi calling here and it works fine, with only pfSense providing NAT.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@JKnott said in At times WiFi calling and sending SMS doesn't work?:
However, first get rid of one of the of the NATs.
Can you please elaborate more on this?
-
@JohnnyBeGood said in At times WiFi calling and sending SMS doesn't work?:
@JKnott said in At times WiFi calling and sending SMS doesn't work?:
However, first get rid of one of the of the NATs.
Can you please elaborate more on this?
Sorry, I had you confused with moikerz, who said one of his customers had double NAT.
-
You'll have to filter on the phone IP address, not MAC address.
MAC filtering works fine, provided a router isn't in the way. I frequently filter on MACs.
@JKnott The Diagnostics > Packet capture page DOES NOT support filtering on MAC address. Had you continued reading you would have seen me say that everything could be captured and subsequently filtered by MAC address in wireshark.
-
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
You'll have to filter on the phone IP address, not MAC address.
MAC filtering works fine, provided a router isn't in the way. I frequently filter on MACs.
@JKnott The Diagnostics > Packet capture page DOES NOT support filtering on MAC address. Had you continued reading you would have seen me say that everything could be captured and subsequently filtered by MAC address in wireshark.
It does here. From the text below the host address box:
"This value is either the Source or Destination IP address, subnet in CIDR notation, or MAC address.
Matching can be negated by preceding the value with "!". Multiple IP addresses or CIDR subnets may be specified. Comma (",") separated values perform a boolean "AND". Separating with a pipe ("|") performs a boolean "OR".
MAC addresses must be entered in colon-separated format, such as xx:xx:xx:xx:xx:xx or a partial address consisting of one (xx), two (xx:xx), or four (xx:xx:xx:xx) segments."That sure looks like it can capture MAC addresses to me.
-
Lol. I do this all day every day and have never used that.
Ahh. Added in 2.4.0. Cool.
Chattanooga, Tennessee, USA
A comprehensive network diagram is worth 10,000 words and 15 conference calls.
DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
Do Not Chat For Help! NO_WAN_EGRESS(TM) -
@JKnott said in At times WiFi calling and sending SMS doesn't work?:
I'll have to look again tomorrow.
I just did that. I captured my phone's traffic, using a Wireshark MAC filter. Like you, I see the ESP protocol listed for the WiFi calling packets. However, you can see at the left, ">" that you can click on to reveal more info. Going down through that info, I can see a VLAN ID 1, priority 3, so they're giving priority to the calls.
Then further down, I see UDP and UDP Encapsulation of IPSec Packets and so on through the rest of the frame.Bottom line, WiFi calling, along with VoLTE, use UDP to encapsulate IPSec, as I mentioned above.
BTW, another thing I see is some NAT keep alive packets.
So, you have to compare when it works with when it doesn't to see if there are any differences.
Also, it would be helpful if you attached the actual packet capture files, rather than a screen capture, so that we can see what's actually happening.
Incidentally, one reason for using UDP is that it makes it easy to move calls between the cell and WiFi networks. If it wasn't used, the IPSec connection would break when moving between networks.
-
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
Lol. I do this all day every day and have never used that.
Ahh. Added in 2.4.0. Cool.
It would be nice if they added MAC addresses to firewall rules. With IPv6, it's pretty much needed with privacy addresses.
