Wifi calling being blocked?



  • Hey Guys having an issue with wifi calling. Specifically port 4500 here are the rules I have:

    Firewall Rules

    Port Forward Nat

    And outbound

    Not sure what I screwed up but right now it appears that port 4500 is being denied by the default deny in the logs anyway. Can anyone think of anything I am missing?



  • Your pfblocker install is probably what's causing the trouble. You can either disable the pfblocker rules to test the theory, or move the wificalling rule above all the pfblocker rules.

    However, if your wificalling device is on your LAN interface, you didn't show those firewall rules. There could be a block there that's the cause. Normally, NOTHING on LAN gets blocked, there's an allow LAN to any destination rule that takes care of that. If you've got block rules above that, or if fpblocker installed some during setup, that could be blocking wificalling.

    We just had a discussion siumilar to this, and it was determined that the cause was IPv6 on the pfsense box itself. Read about it here:

    https://forum.netgate.com/topic/142146/the-firewall-appears-to-be-blocking-outgoing-text-messages-from-my-phone

    Jeff



  • Hello,

    Thanks for the response. So I tried disabling pfngblocker and it didn't have any result. So then I also disabled suricata and still negative results.

    LAN Rules

    I have a work Iphone that will work but the android device will not. Both devices however will work on a non-NAT network that bypasses the firewall. I think the issue started when I tried to change the outbound NAT rules but I'm not sure exactly since I haven't been monitoring wifi calling.

    Are there any specific NAT or firewall rules that may need to be opened for WIFI calling when using hybrid NAT? When I look at the tcpdump I see the device sending over port 4500 but I also see a deny of an incoming carrier packet on port 4500 in the firewall logs. It should also be stated that it used to work fine.

    Also getting out to port 4500 works fine, it seems like the incoming packets are the ones being blocked here:

    [2.4.4-RELEASE][s0m3f00l@pfSense_Edge.fool.local]/home/s0m3f00l: sudo nc -v portquiz.net 4500
    Connection to portquiz.net 4500 port [tcp/sae-urn] succeeded!
    
    HTTP/1.1 400 Bad Request
    ^C
    
    [2.4.4-RELEASE][s0m3f00l@pfSense_Edge.fool.local]/home/s0m3f00l: sudo nc -v portquiz.net 500
    Connection to portquiz.net 500 port [tcp/isakmp] succeeded!
    ^C
    

    IPv6 is turned off and I checked prefer ipv4 in the network settings.

    Blocking:

    [2.4.4-RELEASE][s0m3f00l@pfSense_Edge.fool.local]/home/s0m3f00l: sudo clog /var/log/filter.log | grep 141.207
    Apr  9 05:52:56 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,57508,0,+,17,udp,1500,141.207.151.233,MYIPADDRESS1,4500,16595,2920
    Apr  9 05:52:56 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,57508,1480,none,17,udp,1460,141.207.151.233,MYIPADDRESS1,
    Apr  9 05:52:57 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,58220,0,+,17,udp,1500,141.207.151.233,MYIPADDRESS1,4500,16595,2920
    Apr  9 05:52:57 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,58220,1480,none,17,udp,1460,141.207.151.233,MYIPADDRESS1,
    Apr  9 05:52:59 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,59522,0,+,17,udp,1500,141.207.151.233,MYIPADDRESS1,4500,16595,2920
    Apr  9 05:52:59 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,59522,1480,none,17,udp,1460,141.207.151.233,MYIPADDRESS1,
    Apr  9 05:53:04 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,61349,0,+,17,udp,1500,141.207.151.233,MYIPADDRESS1,4500,16595,2920
    Apr  9 05:53:04 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,61349,1480,none,17,udp,1460,141.207.151.233,MYIPADDRESS1,
    Apr  9 05:53:18 pfSense_Edge filterlog: 9,,,1000000103,mvneta2,match,block,in,4,0x0,,49,281,0,+,17,udp,1500,141.207.151.233,MYIPADDRESS1,4500,16595,2920
    


  • @s0m3f00l said in Wifi calling being blocked?:

    I have a work Iphone that will work but the android device will not.

    Probably an issue with a recent update.
    My iPhone does work with "Wifi calling" using pfSense. I discovered this Wifi calling just a couple of days ago, thanks to the other thread mentioned above..

    What do you maen by :
    @s0m3f00l said in Wifi calling being blocked?:

    Both devices however will work on a non-NAT network that bypasses the firewall. I think the issue started when I tried to change the outbound NAT rules but I'm not sure exactly since I haven't been monitoring wifi calling.

    Never ever you should touch or use NAT in any way to make a phone work.



  • @Gertjan

    What do you maen by :
    @s0m3f00l said in Wifi calling being blocked?:
    Both devices however will work on a non-NAT network that bypasses the firewall. I think the issue started when I tried to change the outbound NAT rules but I'm not sure exactly since I haven't been monitoring wifi calling.

    What I meant is the android device and the Iphone both work on a separate network that has no firewall. And with publicly routable non NAT addressing. Which makes me suspect the issue lies with the PFSENSE device.



  • Can't tell.
    My iPhone works as before, with Wifi calling activated.
    My pfSense (2.4.4p2) has a firewall - that why I use pfSense btw- and I didn't put my any NAT rules. It's a rather basic setup.

    I don't know (again) if it's possible, but I suspect that states get reset ?
    Like your phones opens a long lasting connection to a samsusung server, and without your phone being able to know, this connection get reset ? This could also be the Wifi being dropped - out of range etc.



  • Not sure what you mean. I can see the block messages above.



  • FWIW, my Android phone WiFi calling works fine, even with IPv4 & NAT. WiFi calling uses IPSec on UDP, though I've forgotten the port number. PfSense should be able to handle it fine, without any configuration.



  • FYI

    For what its worth, it was definitely the pfsense box. I make a backup every month and restored to February, without Hybrid NAT and the android phone works now.

    It seems there is an issue with the automatic rules when using hybrid NAT. After making a few NAT UDP rules for the ps4 the issue occurred. So I reverted back to before I made the rules and left pfblocker / suricata on... Bingo it came back up.

    Not sure why that is but it was definitely the sg3100 pfsense box that was causing the issue. And it was definitely to to with NAT since in the NAT table I was getting SINGLE:NO_TRAFFIC AND NO_TRAFFIC:SINGLE for the android device when it was having the issue.

    Broke dick hybrid nat implementation I suppose....



  • ok yea this is almost a year later however:

    had this issue - 2.4.5RC packages installed or not didn't matter, wifi calling and MMS would not work

    was using solely cloudflare dns. yes dnssec ssl/tls

    added google and quad9 dnssec tls/ssl

    (i dont think enabling the checkbox for dnssec or all of the other dnssec extras matter as i had the issue before setting it up as well)

    success

    for me, the problem is the mobile carrier proxy being an RFC 1918 address, pfsense allows this out from what i could tell, even with the rfc 1918 and bogon blocking enabled on the wan not lan (as expected), but i suspect cloudflare might also have these blocked in such a way - which could explain why the return trip would timeout (see next).

    for the return trip, it did not return from their internal proxy but rather their external facing 'exit point' (i verified this by running traceroute from my phone while on cell service with hetools to my wan ip address)

    added their hostnames to whitelist to be safe.

    if i should post this new elsewhere or something, would someone kindly let me know? thanks



  • I was having issues with this several years ago and eventually gave up and got a cell spot from Verizon, and now I don't have any more issues. I did have to fight with them on the phone to send it for free but they did send it. I know this doesn't help solve our issue but I just want to add my two cents that I too was having issues.


Log in to reply