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.
-
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.
-
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.
-
@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.
-
@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.
-
pf doesn't support filtering on MAC addresses at all.
-
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
pf doesn't support filtering on MAC addresses at all.
Yep, that's the problem. IPTables, as used on Linux, does.
-
@JKnott said in At times WiFi calling and sending SMS doesn't work?:
@Derelict said in At times WiFi calling and sending SMS doesn't work?:
pf doesn't support filtering on MAC addresses at all.
Yep, that's the problem. IPTables, as used on Linux, does.
Yes, as everyone is aware.
I do not personally think moving to layer 2 filtering is the correct solution to filtering outbound sourced from IPv6 privacy addresses. Trusted and untrusted segments makes more sense to me. Especially since, as you are obviously aware, MAC addresses can be easily spoofed so no real security is gained there.
-
@JKnott said in At times WiFi calling and sending SMS doesn't work?:
It would be nice if they added MAC addresses to firewall rules. With IPv6, it's pretty much needed with privacy addresses.
Ok, so I tried to compare when I can dial and when I can't but could not see any difference and what is interesting when its working I do not see ESP protocol.
Other screenshot of pfTop is when I i'm on the call it creates connection to .233
When I can't make call over the Wi-Fi I turn it off place the call and it goes through after that when I turrn Wi-Fi on call goes through.Can someone please compare packet_capture.zip logs?
packet_capture.zip -
compare what zips?
-
Attached file to the post. Forum software makes it not that visible.
-
I fixed that for you ;)
In the one you say doesn't work see ESP out to
OrgName: Cellco Partnership DBA Verizon WirelessNo responses.
But in the one you say works, don't see any ESP.. I would guess you missed capturing the actual data.
I see some talk to samsung something, and google - nothing other in that so called working sniff. Like your call actually went out over cell vs wifi.
-
UDP/4500 is performing the same functionality as ESP. It is known as NAT Traversal, or NAT-T.
I would totally expect that for an IPsec client like wifi calling behind a NAT router. It's the same as those micro-cells. They IPsec to home base and all comms are over that too.
-
Pretty sure your talking to the OP there Derelict.. I am quite aware of what ESP and Port 4500 are ;)
My point was there is only 443 traffic in his so called working pcap, and non of it was to what could be a wifi calling system either.. So either his sniff missed when the call was placed, or it didn't go over wifi like he thinks it did.
-
@JohnnyBeGood said in At times WiFi calling and sending SMS doesn't work?:
when its working I do not see ESP protocol.
Yeah, just commenting on that ^
-
Yeah there was no ESP or NAT-T anything, NO anything really when he says it works - a https session to google and one to like *.push.samsungsomething.. Only thing I could make out in the cert - the hello didn't contain actual sni.
Where sure isn't he making a wifi call
So he either missed the traffic with his sniff, or his phone used cell to make the call.
-
I have attached a capture of a WiFi call, so the OP can see what he should be looking for. It contains both the NAT keepalive and actual IPSec traffic, which is identified by ESP, but is in fact a UDP packet encapsulating ESP.
-
^ 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? -
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
.cap
added 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.