PFSENSE WIFI CALLING
-
Haven't checked ...the day got away from me... I will let you know later.
Thank you for your support in this
-
I had a chance to look at this fully... my cellphone is 10.110.9.99 and I look at the pftop session and the cellphone doesn't even reach out to port 4500 or doesn't trigger a UDP port 4500 session
I did make a rule directly allowing 10.110.8.99 cellphone to use port 4500.
Any suggestions?
-
@msa1878 said in PFSENSE WIFI CALLING:
Any suggestions?
Run packet capture, filtering on the IP or MAC address, to see what's happening.
-
Have you looked at your existing states and filtered them based on your phones IP address?
Are all 238 of your wolves using the same carrier? They will probably be all a little different..
Also- is your subnet big enough for all these "customers"? Some of them may not even be connecting if not..
-
The system with 3.2 intel and 16 gigs of ram and 150 gig HD with. Public IP wan attached directly is working with 230 student logged on with maybe two devices between each of them during the day.
On weeknights and weekends, it's about 80 students. Side note... I didn't notice this issue or received any reports of this issue until I turned on captive portal and require all students to authenticate against Google Gsuite secure Ldap services. I also installed snort and PFblocker and have since turn these off, except for the captive portal due to this issue. The campus has all sorts of carriers but Verizon is the primary Im dealing with for now.
These add-ons should not have any reason why wifi calling shouldn't work.
Someone correct me if I'm missing something
Tim
-
Did you try allowing external DNS requests? Or logging blocked DNS requests?
-
I check that and it is set as you suggested.
-
We are using external dns services but I have the server rule allowing PFsense dns only and blocking all other dns server request just in case a student tries to change his dns to outwit my firewall.
-
Yes, I see that but if, for example, the wifi calling app is hard coded to use 8.8.8.8 if will fail. You should add DNS redirect as well as just blocking it to be sure.
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.htmlThe fact you are not seeing any port 4500 traffic implies it's not even trying which could be a DNS problem. You should also check for port 500 traffic though.
Steve
-
@stephenw10 said in PFSENSE WIFI CALLING:
Yes, I see that but if, for example, the wifi calling app is hard coded to use 8.8.8.8 if will fail.
Assuming we're talking about the WiFi calling that's built into the phone, it might not need to use DNS. The IP address could be supplied directly by the carrier. I have not checked to see whether DNS is used or not.
-
Possible but I'd be very surprised if they were using hard coded IPs. It makes maintaining a network to support all those clients very inflexible.
Denying external DNS is about the only non-standard thing happening here so I'd certainly test just allowing it.
Steve
-
I don't know about hard coded, but it could certainly be configured via the carrier. I'll have to check later about whether DNS is used.
-
I found dialercallinfolookup-pa.googleapis.com, which might have something to do with it.
host dialercallinfolookup-pa.googleapis.com
dialercallinfolookup-pa.googleapis.com has address 142.251.33.170
dialercallinfolookup-pa.googleapis.com has address 142.251.41.74
dialercallinfolookup-pa.googleapis.com has address 172.217.165.10
dialercallinfolookup-pa.googleapis.com has address 142.251.32.74
dialercallinfolookup-pa.googleapis.com has address 142.251.41.42
dialercallinfolookup-pa.googleapis.com has address 172.217.1.10
dialercallinfolookup-pa.googleapis.com has IPv6 address 2607:f8b0:400b:803::200a
dialercallinfolookup-pa.googleapis.com has IPv6 address 2607:f8b0:400b:80f::200a
dialercallinfolookup-pa.googleapis.com has IPv6 address 2607:f8b0:400b:80c::200a
dialercallinfolookup-pa.googleapis.com has IPv6 address 2607:f8b0:400b:804::200ahost 142.251.32.74
74.32.251.142.in-addr.arpa domain name pointer yyz12s07-in-f10.1e100.net.host 2607:f8b0:400b:804::200a
a.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.4.0.8.0.b.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa domain name pointer yyz10s20-in-x0a.1e100.net.YYZ is the airport code for Toronto's Pearson airport, which is a few miles from here.
On the other hand, Google indicates it might be a spam or scan address.
-
This post is deleted! -
OK good morning I am now truly stumped!
I have changed my DNS from the resolver to the DNS forwarder and still nothing. I can see my cellphone connect to port 500 using PFTOP. No port 4500 sessions at all. I have removed every rule thinking it was blocking. Nothing!
I even tried a different WIFI access point ... nothing?
-
Ok do you see any replies on port 500?
What do the port 500 states look like? If it's not using a static source port for the outbound NAT on port 500 that can cause it to fail. Though anything recent should not.
-
-
I would just use the state table so you can see the translations directly.
What IP is the phone?
-
OK.... so i figured out what is stopping the wifi calling udp 4500 not working... As I mention few posts back...we are using the captive portal to authenticate the students. I just turned off the capture port a few minutes ago and the wifi calling started working.
We need the captive portal back...what is the captive portal doing to stop wifi calling?
-
OK...as i mentioned, I am using the captive portal to make all students authenticate their devices. I just turned it off since I had exhausted all other avenues of solutions. and guess what.....Now wifi calling works.
Any chance someone would know why the captive portal would not allow all traffic after authentication?
