PFSENSE WIFI CALLING
-
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?
-
Hmm, interesting. I would still look at the state tables in each case so you can see the states and NAT being applied and on which interfaces.
I assume you are testing after phones have logged into the captive portal?
-
FOUND THE ISSUE.
PF 2.6 captive portal has been written with missing code in the default build. A fix was posted 11 months ago. CP was coded only to allow TCP traffic everything else was blocked.
Beginners would never have known.
A big Thank you to all that helped...https://redmine.pfsense.org/issues/12834
-
What you could do is put the WiFi calling on a VLAN and separate SSID, to avoid Captive Portal.
-
Ah of course! Yes I should have known that, sorry. I guess I've been testing 2.7/23.01 for too long, where it's fixed.
