At times WiFi calling and sending SMS doesn't work?
-
^ exactly there is 2 way communication there ;) Kind of a given for any sort of call to be going on...
-
@johnpoz said in At times WiFi calling and sending SMS doesn't work?:
Where sure isn't he making a wifi call
Here's the video I made showing what I was doing https://youtu.be/q-iVQqJ_wA0
Am I doing something wrong?I like to fill my tub up with water, then turn the shower on and act like I'm in a submarine that's been hit!
-
Not going to watch a video... If you can not post a sniff showing traffic then no traffic is happening..
Your sniff showing when a call worked had ZERO traffic in that could be a call.
Your call showing when didn't work showed some traffic hitting the lan, so sniff on the wan did it go out? If goes out and no answer - that has zero to do with pfsense.
-
packetcapture (4).zip @johnpoz said in At times WiFi calling and sending SMS doesn't work?:
Not going to watch a video... If you can not post a sniff showing traffic then no traffic is happening..
Your sniff showing when a call worked had ZERO traffic in that could be a call.
Your call showing when didn't work showed some traffic hitting the lan, so sniff on the wan did it go out? If goes out and no answer - that has zero to do with pfsense.Attached is the packet capture as shown in the video.
Call was never answered. "Calling" on the phone screen and silence as it was trying to place the call.I'm willing to post whatever is needed in order to get to the bottom of this.
-
@JohnnyBeGood said in At times WiFi calling and sending SMS doesn't work?:
Am I doing something wrong?
Yeah, trying to show what you're doing with a video. I just watched it and it's of absolutely no use.
Do as I did, that is run Wireshark capturing only the WiFi calling. You should have the IP address of where the call is going. Filter on that, while placing a call. Also, allow enough time to capture some of the keep alive packets. When that's done, post the capture here.
-
Here's another capture of when it works and of course ESP are shown.
packetcapture (6).zip.
@JKnott said in At times WiFi calling and sending SMS doesn't work?:
Do as I did, that is run Wireshark capturing only the WiFi calling. You should have the IP address of where the call is going. Filter on that, while placing a call. Also, allow enough time to capture some of the keep alive packets. When that's done, post the capture here.
Ok, when you did your capture you used your phone's private IP on the LAN, correct?
-
Any reason why you zipped it? By zipping it, I have to download it, unzip it, then run Wireshark with the extracted file. If you just attach the capture file, it opens Wireshark directly.
-
@JKnott said in At times WiFi calling and sending SMS doesn't work?:
Any reason why you zipped it? By zipping it, I have to download it, unzip it, then run Wireshark with the extracted file. If you just attach the capture file, it opens Wireshark directly.
Sorry but the forum does not allow me to upload it without zipping it first.
-
@JohnnyBeGood said in At times WiFi calling and sending SMS doesn't work?:
Sorry but the forum does not allow me to upload it without zipping it first.
I had no problem doing that. Take a look at my post.
-
I'll see about getting
.capadded to the allowed list of prefixes.Actually, looking at it, it is probably easier to rename the file to .pcap than to zip it.
-
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
I'll see about getting .cap added to the allowed list of prefixes.
Yeah, it's a bit strange the pfSense forum won't accept files created by pfSense packet capture.
-
so you can see answers there but not when doesnt work... So now sniff on the WAN it doesn't work... Do you see answers? Do you see it sending to that 141.207.229.233 IP?
-
FYI: .cap files now allowed in file uploads.
-
@johnpoz said in At times WiFi calling and sending SMS doesn't work?:
so you can see answers there but not when doesnt work... So now sniff on the WAN it doesn't work... Do you see answers? Do you see it sending to that 141.207.229.233 IP?
Below is capture of WAN port when it does not work. I let it sit for some time and on the phone it just shows calling but nothing is happening.
packetcapture (7).capHere's the capture of about 5+ minutes later when it works.
packetcapture (8).capTo me both captures look similar?
-
Was this problem ever solved?
I have a Galaxy S8+ and SG-3100 pfSense Security Gateway Appliance.
New install and having the same issue. -
No, it was not. You will never get confirmation from Netgate that anything is wrong but I'm using pfSense for years (6+) with WiFi calling and never had issues. One of last few (maybe more) updates broke it. Most likely introduction of Automatic outbound NAT rule generation.
(IPsec passthrough included) is just my guess.
I found other posts here and other places mentioning the same problem:
https://forum.netgate.com/topic/142370/wifi-calling-being-blocked
https://www.reddit.com/r/PFSENSE/comments/c7ze1s/at_times_wifi_calling_and_sending_sms_doesnt_work/
https://www.reddit.com/r/PFSENSE/comments/bkgj0t/issue_with_pfsense_ipv6_and_sms/emk3vvc/I solved it by turning OFF Automatic outbound NAT rule generation.
(IPsec passthrough included) and switched to Manual Outbound NAT rule generation.
(AON - Advanced Outbound NAT) and manually mapped 4500 port. So far for the past 2 weeks I have not had any failed SMS or phone calls while on the WiFi. It defiantly did the trick in my case. Hope it helps someone!
-
That is nothing new.
If they changed something to require static outbound NAT for NAT-T (UDP/4500) then they essentially broke the whole point of NAT-T.
This is not pfSense's fault. This is your Wi-Fi calling provider's fault.
-
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
NAT-T (UDP/4500
I agree that this issue might have something to do with Verizon but I also think if this would be a wide spread issue with other off the shelf routers than internet searches would be filled with it but somehow this only affects pfSense from what I was able to come across.
-
@JohnnyBeGood It's just NAT. If they did something stupid to require static source port 4500, the knob is there for you to turn. That will break if multiple phones try to connect to the same IPsec endpoint.
These are my states to AT&T. NAT-T doing what NAT-T does:
Packets Bytes LAN udp 192.168.223.223:4500 -> 129.192.166.10:4500 MULTIPLE:MULTIPLE 33.68 K / 25.353 K 4.87 MiB / 5.07 MiB WAN udp 203.0.113.230:31513 (192.168.223.223:4500) -> 129.192.166.10:4500 MULTIPLE:MULTIPLE 33.678 K / 25.353 K 4.87 MiB / 5.07 MiB -
This post is deleted!
