We have a 3CX v20 with a simple setting (1 main number, 4 SDA).
3CX APP on I-phones can receive call "ok" when we are on the LAN (connected through WiFi) or when we are on other networks connected through WiFi.
But as soon as we get on a 4/5G network, the connectivity button turns grey and no call can be received.
I am not sure why exactly… It used to work with v.18 -- and not anymore.
There is absolutely not pb with ports.
NetworkPorts:
SIP:5060
SIPS:5061
Tunnel:5090
Media:9000-10999
HTTP:80
HTTPS:443
Everything is opened as it should.
We receive calls, we can make calls, but when we roam outside of a WiFi (wether on our LAN or on other WiFi Network), it does not connect -- presence icon on top right becomes grey…
The presence indicator turns green every time I am on a WiFI network, and greys when I roam to 4/5G network - and of course I can also access the admin panel and receive call from there.
This is likely the issue. We have run into this before. My guess is that on mobile data you are making use of IPv6, whereas on WIFI networks, it is IPv4 only.
Over the past few months it appears Apple and Google have added IPv6 endpoints for Google Firebase and Apple Push (Where you get notified of an incoming call).
A few options:
- Disable IPv6 in /etc/network/interfaces
- Comment out all "ip6" in /etc/nftables.conf
- Modify /etc/nftables.conf to be compatible with icmpv6. You can test before and after the edit with ping -6 firebaseinstallations.googleapis.com
To make it IPv6 compatible;
Move this section,
Code:
ip daddr 224.0.1.75 counter accept comment "Accept SIP Multicast"
fib daddr type broadcast drop comment "Drop other broadcast"
fib daddr type multicast drop comment "Drop other multicast"
fib daddr type anycast drop comment "Drop other anycast"
ip daddr 224.0.0.0/4 drop comment "Drop DVMRP"[
Underneath this section.
Code:
# ICMPv4
ip protocol icmp icmp type {
echo-reply, # type 0
destination-unreachable, # type 3
time-exceeded, # type 11
parameter-problem, # type 12
} accept comment "Accept ICMP"
ip protocol icmp icmp type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
# ICMPv6
icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,
nd-router-advert,mld-listener-query,destination-unreachable,
packet-too-big,time-exceeded,parameter-problem} accept
ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
If you are Linux savvy, here are some instructions. cp /etc/nftables.conf /etc/nftables.backup
nano /etc/nftables.conf
nft -c -f /etc/nftables.conf
systemctl restart nftables
So you should have something like this:
(Keep in mind I have not tested what is below, I have only tested our custom ruleset.)
Code:
#!/usr/sbin/nft -f
# vim:set ts=4:
# You can find examples in /usr/share/nftables/.
# Default NFTables V20
# Clear all prior state
flush ruleset
# Basic IPv4/IPv6 stateful firewall for server/workstation.
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iifname lo accept comment "Accept any localhost traffic"
ct state { established, related } accept comment "Accept traffic originated from us"
ct state invalid drop comment "Drop invalid connections"
tcp dport 113 reject with icmpx type port-unreachable comment "Reject AUTH to make it fail fast"
# 3CX PhoneSystem specific
tcp dport { 80,443,5000,5001,5015,5060,5061,5090 } ct state new counter accept comment "Accept 3CX PhoneSystem TCP ports"
udp dport { 69,5060,5090,7000-10999 } counter accept comment "Accept 3CX PhoneSystem UDP ports"
# Other services specific
udp dport { 137,138 } counter accept comment "Accept NetBIOS"
tcp dport { 139,445 } counter accept comment "Accept TCP/IP MS Networking"
# SSH Bruteforce blacklist
tcp dport ssh ct state new limit rate 15/minute accept comment "Avoid brute force on SSH"
# ICMPv4
ip protocol icmp icmp type {
echo-reply, # type 0
destination-unreachable, # type 3
time-exceeded, # type 11
parameter-problem, # type 12
} accept comment "Accept ICMP"
ip protocol icmp icmp type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
# ICMPv6
icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,
nd-router-advert,mld-listener-query,destination-unreachable,
packet-too-big,time-exceeded,parameter-problem} accept
ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
# Block *cast packets we haven't already accepted
ip daddr 224.0.1.75 counter accept comment "Accept SIP Multicast"
fib daddr type broadcast drop comment "Drop other broadcast"
fib daddr type multicast drop comment "Drop other multicast"
fib daddr type anycast drop comment "Drop other anycast"
ip daddr 224.0.0.0/4 drop comment "Drop DVMRP"
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
In my opinion if you don't require IPv6, the easiest solution is to disable IPv6.
I hope this provides you some direction. Let us know how it goes.
I am able to access the webclient from the phone, connected through 5G, but it will randomly say that "can not open the page because no secure connexion can be established". But if I reload the page it will go through…
Isn't there a pb with IPv6 and certs ?
Because from the log in the 3cx, I can only see connexion made from the IPv4 of the telco operator -- and I know they are using dual stack…
Do you have IPV6 enabled on the 3cx side under the admin console > settings > network section? And does the 3cx system machine have a valid dual-stack IPV6 configuration on the Nic?
You can also enable the verbose logging on the 3cx mobile app from the settings section within the app and then close the app, join your mobile data network, and re-open the app.
Check if the status box is grey (no presence). If it says ready for calls, then it is connecting via the tunnel towards the 3cx system. You need to check what ports 5001 is being blocked. Maybe the firewall is dropping packets, some security services are enabled, or SSL inspection is not allowing the connection.
If both the status boxes are grey and not ready for calls, then both TCP port 5001 (if this is your https port) and tunnel connection are not possible.
In both cases, send the log from the app to your email and check through it for any clues.
This is likely the issue. We have run into this before. My guess is that on mobile data you are making use of IPv6, whereas on WIFI networks, it is IPv4 only.
Over the past few months it appears Apple and Google have added IPv6 endpoints for Google Firebase and Apple Push (Where you get notified of an incoming call).
A few options:
- Disable IPv6 in /etc/network/interfaces
- Comment out all "ip6" in /etc/nftables.conf
- Modify /etc/nftables.conf to be compatible with icmpv6. You can test before and after the edit with ping -6 firebaseinstallations.googleapis.com
To make it IPv6 compatible;
Move this section,
Code:
ip daddr 224.0.1.75 counter accept comment "Accept SIP Multicast"
fib daddr type broadcast drop comment "Drop other broadcast"
fib daddr type multicast drop comment "Drop other multicast"
fib daddr type anycast drop comment "Drop other anycast"
ip daddr 224.0.0.0/4 drop comment "Drop DVMRP"[
Underneath this section.
Code:
# ICMPv4
ip protocol icmp icmp type {
echo-reply, # type 0
destination-unreachable, # type 3
time-exceeded, # type 11
parameter-problem, # type 12
} accept comment "Accept ICMP"
ip protocol icmp icmp type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
# ICMPv6
icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,
nd-router-advert,mld-listener-query,destination-unreachable,
packet-too-big,time-exceeded,parameter-problem} accept
ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
If you are Linux savvy, here are some instructions. cp /etc/nftables.conf /etc/nftables.backup
nano /etc/nftables.conf
nft -c -f /etc/nftables.conf
systemctl restart nftables
So you should have something like this:
(Keep in mind I have not tested what is below, I have only tested our custom ruleset.)
Code:
#!/usr/sbin/nft -f
# vim:set ts=4:
# You can find examples in /usr/share/nftables/.
# Default NFTables V20
# Clear all prior state
flush ruleset
# Basic IPv4/IPv6 stateful firewall for server/workstation.
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iifname lo accept comment "Accept any localhost traffic"
ct state { established, related } accept comment "Accept traffic originated from us"
ct state invalid drop comment "Drop invalid connections"
tcp dport 113 reject with icmpx type port-unreachable comment "Reject AUTH to make it fail fast"
# 3CX PhoneSystem specific
tcp dport { 80,443,5000,5001,5015,5060,5061,5090 } ct state new counter accept comment "Accept 3CX PhoneSystem TCP ports"
udp dport { 69,5060,5090,7000-10999 } counter accept comment "Accept 3CX PhoneSystem UDP ports"
# Other services specific
udp dport { 137,138 } counter accept comment "Accept NetBIOS"
tcp dport { 139,445 } counter accept comment "Accept TCP/IP MS Networking"
# SSH Bruteforce blacklist
tcp dport ssh ct state new limit rate 15/minute accept comment "Avoid brute force on SSH"
# ICMPv4
ip protocol icmp icmp type {
echo-reply, # type 0
destination-unreachable, # type 3
time-exceeded, # type 11
parameter-problem, # type 12
} accept comment "Accept ICMP"
ip protocol icmp icmp type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
# ICMPv6
icmpv6 type {echo-request,nd-neighbor-solicit,nd-neighbor-advert,nd-router-solicit,
nd-router-advert,mld-listener-query,destination-unreachable,
packet-too-big,time-exceeded,parameter-problem} accept
ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 1/second accept comment "Accept max 1 ping per second"
# Block *cast packets we haven't already accepted
ip daddr 224.0.1.75 counter accept comment "Accept SIP Multicast"
fib daddr type broadcast drop comment "Drop other broadcast"
fib daddr type multicast drop comment "Drop other multicast"
fib daddr type anycast drop comment "Drop other anycast"
ip daddr 224.0.0.0/4 drop comment "Drop DVMRP"
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
In my opinion if you don't require IPv6, the easiest solution is to disable IPv6.
I hope this provides you some direction. Let us know how it goes.
I have taken the simple path and got rid of IPv6 (which is sad, because the latency that we have with IPv6 is quite fantastic).
The latency that we have with IPv4 is also excelent !
Anyway, had to re-provision my account and everthing is now "ok" and "green".
Thanks a lot - excellent support. Congratulation.
