PFSENSE WIFI CALLING
-
@mikeisfly interesting. I didn’t have to make any changes. I have VZW
-
You should not have any rules allowing that IPSec traffic inbound. So not on WAN or as Floating rules applied to WAN. All the IPSec connections for that are opened outbound.
The wifi calling might be trying to use some hardcoded DNS which would be blocked by your rules.
-
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?
