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