PFSENSE WIFI CALLING

[JKnott]

@jknott

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::200a

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

[msa1878]

This post is deleted!

[msa1878]

@msa1878

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?

[stephenw10]

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.

[msa1878]

@stephenw10

Port 500 looks good and port 4500 nothing see attachments

[stephenw10]

I would just use the state table so you can see the translations directly.

What IP is the phone?

[msa1878]

@stephenw10

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?

[msa1878]

@msa1878

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?

[stephenw10]

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?

[msa1878]

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

[JKnott]

@msa1878

What you could do is put the WiFi calling on a VLAN and separate SSID, to avoid Captive Portal.

[stephenw10]

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.

[Gertjan]

@stephenw10
On the other hand, "2.6.0" introduced the pfSense "System_Patches" package with some pre build in 'must have' patches. A thing is : it should be outlined somewhere that package is a must have, for any pfSense version.
The issue that the captive portal was 'TCP' only for a while was such a show stopper that a solution and patch was found right from the start.

I left 2.6.0 also myself as Netgate device uses 'Plus', so I'm not entirely sure right now (I don't recall).

Also : the topic is wrongly placed and named.
Wifi calling works just fine.
BUT : It only fails when the captive portal is used. So its a portal (forum) issue.

This is the perfect description of the issue :

@msa1878 said in PFSENSE WIFI CALLING:

Any chance someone would know why the captive portal would not allow all traffic after authentication?

The captive allows what you allow it to pass, using the GUI firewall rules.
A rule with IPv4 any protocol any port any address will pass everything.
The TCP only issue would have popped out of my mind right away.

[stephenw10]

Mmm, until we knew the CP was the issue we only discovered it because IPSec would not pass initially. OP was not to know the cause in advance.

[michmoor]

@stephenw10 lots of CP changes in the new releases i see. I didnt know about the TCP only issue. I dont think i hit that bug or maybe im not aware. I do grab all the latest patches and firmware upgrades when i deploy the 6100s.

[Gertjan]

@michmoor said in PFSENSE WIFI CALLING:

lots of CP changes in the new releases i see

You mean 22.05 as you talk about a 6100 ?

22.05 doesn't use the good old second firewall 'ipfw', as 2.6.0, but uses a new, modified 'pf' so it can also handle MAC ( ! ). It was Netgate that changed 'pf' upstream for the entire FreeBSD community
22.05 native has issues : the "one queue for all connected users" is one of them. There is a patch.
Look quickly over the last 10, 20 (skip the please help posts) captive portal forum posts, you find them all.

If you are a heavy (hundreds of connected users) portal consumer, then watch your memory as there is a small memory leak in the new pf code. This can't be patched, as it needs binary changes, and the upcoming 23.0x will solve that.