Wifi Callings not working
-
@nicolas-pissard If it were me I would pick a test device that you control and place a pass any any any rule at the top for just that source address and see if it works.
Alternately look at the firewall logs for that source address and see what's being blocked and pass it.
It's going to be up to you to find out what that wifi calling service needs and pass it.
It should work no problem with the default rule set. All it is is an outbound IPsec session.
No, you should not need any WAN rules. WiFi calling is and outbound connection only. Everything else is over the tunnel.
Chattanooga, Tennessee, USA
A comprehensive network diagram is worth 10,000 words and 15 conference calls.
DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
Do Not Chat For Help! NO_WAN_EGRESS(TM) -
thank you for your reply.
I tried by putting a simple rule that opens all ports without exceptions, same result...
I specify that I am on a private network in a high school behind a Fortigate firewall...
I confess that I am lost...
-
@nicolas-pissard Just as a heads up, there are WiFi solutions out there that filters broadcast and wificalling depending on configuration (but filtered by default).
Are you sure your WiFi is just a layer 2 network extension of the Firewall VLAN, or does your WiFi perhaps optimize bandwidth with filtering functions?
-
To test, I used another WLAN network but the latter does not use the pfsense captive portal. In this case it works. But as soon as I use the one with the pfsense, it doesn't work...
-
@Derelict said in Wifi Callings not working:
It should work no problem with the default rule set. All it is is an outbound IPsec session.
Actually, it's IPSec in UDP. The UDP encapsulation is necessary because NAT breaks IPSec. It also makes it easier to roam between WiFi and the cell network.
-
@nicolas-pissard said in Wifi Callings not working:
I specify that I am on a private network in a high school behind a Fortigate firewall...
Your problem might not be with pfSense. If there's another firewall there, it could have rules that block WiFi calling. You likely also have double NAT, which can really mess things up. Can you try with a network that you control, such as at home?
Many organizations lock down their networks, so you can only do what they want. For example, at my local library, I can use a browser and nothing else. I can't even use an email app or OpenVPN.
-
Captive portal? They are going to have to punch through that before anything will work.
-
Captive portal => a 'default' 2.6.0, installed from the USB/ISO will break things.
When 2.6.0 came out, only TCP ( !! ) worked over the interface that has been set up with a captive portal.
No UDP, no ICMP.You have to install the System patches pfSense package.
In contains several 'must have' patches, one of the corrects the ipfw portal firewall handling.Btw : ones the portal user is connected to the portal, all ports, all protocols can be sued.
No need to NAT or do what so ever.
You'll be needing a GUI firewall rule like this :
on the captive portal interface of course.
-
Hello I hope this link can help you, it did for me. I spliced all these connections with the Proxy.
Ref:
https://support.google.com/work/android/answer/10513641?hl=enIf your using an Android Smartphone you need the following ports open
TCP/UDP 5228-5230
TCP 5235,5235
(also ref website above you need to allow traffic to the the destination hosts also if you are using a proxy)Androids would not work on my network until I approved those ports and hosts
Just some of the regex expressions I used for this in my splice file.
play.google.com
android.com
^((alt[0-9]-mtalk.)|(mtalk.)|(mtalk-(staging|dev).))google.com
google-analytics.com
googleusercontent.com
gstatic.com
^((gvt)([0-9])).com
ggpht.com
dl.google.com
dl-ssl.google.com
android.clients.google.com
^(((clients)[0-9])|accounts).google.(com|us)
connectivitycheck.android.com
android.clients.google.com
device-provisioning.googleapis.com
connectivitycheck.gstatic.com
payments.google.com
googleapis.com
notifications.google.com
ogs.google.com
googleapis.com
androidmanagement.googleapis.com
^(pki|(crl|ocsp).pki).google.com -
Hi,
Thanks Gertjan for your answer
Thank you I had already installed the "System_Patches" package but I just updated it.
I've also enabled logging on wifi call rules and I'm seeing traffic going through.
But I don't see anything on port 4500 and on the phone, wifi calls are still not active...
-
I have authorized frames on the firewall for port 500 and 5228 but wifi calls are not active on the phone (I don't have the icon at the top right). What I find strange is that I never have a trace for port 4500...
Is a NAT rule missing?
-
@nicolas-pissard said in Wifi Callings not working:
Is a NAT rule missing?
No NAT needed. No special tricks needed. Why do you think you need to NAT something ?
Just one firewall rule on the captive portal firewall rule page, the the firewall rule I've showed you above.I'm using the portal also, and when I connect my phone, I can do whatever I want. Visit whatever I want. All ports are open (for outgoing connections).
True : I use 23.05.
But back then, when I was using 2.6.0 - with the patch, the portal worked well.Show your captive portal firewall rules.
Undo everything else.If you have Youtube, go here : Youtube Netgate.
Look at every Captive portal video you can find (there are 3 of them).
They are rather old, but still very valid. -
I tested with the rule that allows everything.
However, wifi calls do not work. I don't have the icon at the top right of my phone...
I don't know where to look anymore.
something to configure in the System > Advanced > Firewall & NAT tab?
-
@nicolas-pissard said in Wifi Callings not working:
something to configure in the System > Advanced > Firewall & NAT tab?
Noop. Pas besoin de changer quoi que ce soit la-bas.
The phone you use, did you connect to the portal ? You saw the login page ?
When authenticated, do you see this on the pfSense dashboard :
Do you have a phone ? Connect it. Install some network testing apps. Test DNS, as this uses normally UDP (can use TCP). It should work.
I'm not sure how to test UDP access.
When I take my iPhone, and connect to the portal, I can 'call' using whatever.
That is, dono what Wifi calling is actually. Why would I need that ?
Our/my ISP is Orange France (fibre).If your far from "47500", drop by, I'll show you ;)
Calling using Whatsapp, telegram and I don't know what : works fine.
I can get called also. -
I'm actually using a captive portal.
However, I added my phone as authorization by mac address.
On other forum topics, I find that there may be a DNS forwarding issue.
Also I use DNS Resolver for blocking Domain Overrides.
How to set up DNS port forwarding on NAT?
-
@nicolas-pissard said in Wifi Callings not working:
However,
When setting up things, keep everything simple - as basic as possible
No MAC adding. No IP allow, nothing.
Connect your device, check that you see the login page. Login with valid credentials.
Check the pfSense GUI that you are logged in.
Can you visit, for example google.com ?
Can you visit ... www.tf1.fr (tf1.fr wasn't in your local D?NS cache, this test validates DNS lookups).@nicolas-pissard said in Wifi Callings not working:
How to set up DNS port forwarding on NAT?
You mean this : Redirecting Client DNS Requests ?
Such a redirect is optional.
True, there are people that 'insist' in using their DNS, not the DNS the device got by DHCP.
That's actually their choice.
A side effect is : they can't use the free (portal !!) wifi access at mac Donald's, neither Air France, neither SNCF. And yes, neither your wifi portal. It's their choice ;) Their choice can't be your issue.But, yes, I admit, I also feel bad for those people.
So I actually did what was explained on that "Redirecting Client DNS Requests" :
but again : this is not needed to make things work.
It's just an anti-shoot-in-the-foot measure.These are the first 3 rules of my captive portal :
The first one is the firewall rule that was added by the NAT rule.
As you can see, the counter in front of the rules are not zero : so this firewall rule (and redirecting) has been activated for some portal visitors.
Most (low bud !) phones - or their even more stupid (sorry) owners insist on using their own DNS IP : they got redirected to ..... pfSense 127.0.0.1 so the resolver can do it's work for them. If this wasn't they case, DNS would not work for them (as initially the portal doesn't allow any external access !!).
Happily enough : this is a small minority.The second rule authorizes express all DNS traffic to the pfSense Portal interface : these counters are way higher : which shows most devices to play by the rules : they use the DNS that pfSense DHCP has been given to them
The third rule : This is a safe barrier. If I missed something then let them (the portal visitor) take the wall. This rule is never used, so I took care of all the port 53 TCP/UDP traffic.
@nicolas-pissard said in Wifi Callings not working:
Also I use DNS Resolver for blocking Domain Overrides.
Just for my own curiosity :
First : you add domain overrides.
Then : you have to block them ?I have a domain override :
Where 192.168.2.1 is my pfSense portal IP network.
I need to have a host name, as I'm using https portal login page. Http is pretty dead these days, and most browser just don't allow it anymore, or start to yell 'security issue ahead' !
Portal visitors will panic and say to you : "problem" ?!
https usage is optional, of course.
