PFSENSE WIFI CALLING

[mikeisfly]

@marvosa making this change is what worked for me.

[stephenw10]

Just to be clear you should never need to open inbound ports for this. If you are blocking outbound traffic you may need to open ports there.

[msa1878]

@nollipfsense

Thank you for any advanced help with this matter. as you can see I have tried every thing

TIm

[michmoor]

@msa1878 take one phone. Create an any/any rule for that one phone in your rules. Then see if WiFi calling works. See what states it creates using pftop.

[msa1878]

@michmoor

Would this rule reside on the lan rule or wan or floating? this is what I added per your suggestion.

Tim

[michmoor]

@msa1878 I’m not understanding your rules. You have two rules that permit any/any. Just seeing that, WiFi calling should work.

[msa1878]

@michmoor

Removed the redundant rules shown.

[michmoor]

@msa1878 I just wanted you to put in a new rule with the source IP being the phone you want to test BUT is WiFi calling working?

[mikeisfly]

@msa1878

System -> Advance -> Firewall & NAT -> change Firewall Optimization Options to Conservative.

This is what worked for me. I have Verizon wireless. Before I made this change it would be hit or miss. After the change everything is working as expected.

[michmoor]

@mikeisfly interesting. I didn’t have to make any changes. I have VZW

[stephenw10]

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.

[msa1878]

@michmoor

Haven't checked ...the day got away from me... I will let you know later.

Thank you for your support in this

[msa1878]

@michmoor

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?

[JKnott]

@msa1878 said in PFSENSE WIFI CALLING:

Any suggestions?

Run packet capture, filtering on the IP or MAC address, to see what's happening.

[chpalmer]

@msa1878

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..

[msa1878]

@chpalmer

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

[stephenw10]

Did you try allowing external DNS requests? Or logging blocked DNS requests?

[msa1878]

@mikeisfly

I check that and it is set as you suggested.

[msa1878]

@stephenw10

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.

[stephenw10]

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.html

The 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