Hi,
We have an issue with SIP packets through our Mikrotik hAP ac Lite. We have a VoIP-device in the network, but it is not receiving incoming calls.
When we make some traces we see that the VoIP-PBX is sending SIP INVITES, they are reaching the router. But not forwarded to the VoIP-device in the network.
What can be the problem and how to solve this?
I’ve attached a packet sniff on the Mirkotik.
Best regards,
Joost Lauwen
please post your config
/interface bridge
add admin-mac=64:D1:54:56:0C:8E auto-mac=no comment=defconf name=bridge
/interface ethernet
set [ find default-name=ether1 ] advertise=
10M-half,10M-full,100M-half,100M-full,1000M-half,1000M-full comment=
UPLINK speed=1Gbps
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip pool
add name=default-dhcp ranges=192.168.1.10-192.168.1.254
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.1.1/24 comment=defconf interface=bridge network=
192.168.1.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server lease
add address=192.168.1.252 mac-address=00:0D:B9:49:B4:16 server=defconf
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf dns-server=8.8.8.8,8.8.4.4
gateway=192.168.1.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall address-list
add address=x.x.x.x list=RemoteManagement
add address=x.x.x.x list=PINGlist
add address=x.x.x.x list=PINGlist
add address=x.x.x.x list=AXS2COM
/ip firewall filter
add action=accept chain=input comment=
“defconf: accept established,related,untracked” connection-state=
established,related,untracked
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack”
connection-state=established,related
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
src-address-list=PINGlist
add action=accept chain=input comment=“Allow Remote Management”
src-address-list=RemoteManagement
add action=drop chain=input comment=“defconf: drop invalid” connection-state=
invalid
add action=drop chain=input comment=“Drop External Acces to DNS” dst-port=53
in-interface-list=WAN protocol=tcp
add action=drop chain=input dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=input comment=“Block External Acces to Ports” dst-port=
21,22,23,80,443,8291,8728,8729 in-interface-list=WAN protocol=tcp
add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN
add action=accept chain=forward comment=“defconf: accept in ipsec policy”
ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy”
ipsec-policy=out,ipsec
add action=accept chain=forward comment=
“defconf: accept established,related, untracked” connection-state=
established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid”
connection-state=invalid
add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment=“defconf: masquerade”
ipsec-policy=out,none out-interface-list=WAN
/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set irc disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes
set udplite disabled=yes
set dccp disabled=yes
set sctp disabled=yes
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www port=50080
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/tool sniffer
set file-name=sniff.pcap filter-ip-protocol=udp filter-port=sip,rtp
Is the phone registered with the PBX? If there is no connection (under IP > Firewall > Connections) the incoming packets have nowhere to go and will be dropped.
There is little point setting 1000M-half,1000M-full on ether1 as the device only supports fast, not gigabit, ethernet.
The Drop External Acces to DNS and Block External Acces to Ports input rules are unnecessary due to the defconf: drop all not coming from LAN rule.
Hi tdw,
Yes, the Anynode-device is registered to our PBX. And it is registering every 3 minutes.
Best regards,
Joost Lauwen
We always disable SIP helper in MikroTik and this solve us problems. IP > Firewall > Service Ports
We’ve already disabled SIP ALG/Helper in the config. Without any success.
I’ve also tried to create a NAT-rule to forward all the SIP-traffic to the IP-address of the VoIP-device.
The device is not a standard VoIP-phone, like Cisco, Gigaset. But an AnyNode SBC.
Do you see the registration messages between the Mikrotik and SBC in the packet trace in both directions (SBC → Mikrotik and Mikrotik → SBC)
Yes, I see the REQUEST, REGISTER and BINDING packages.
So the registration packages are OK.
Yes, the Anynode-device is registered to our PBX. And it is registering every 3 minutes.
Have you tried to increase the udp-stream-timeout to 5m in /ip/firewall/connection/tracking ?
The default value is 3m (minutes), same as your phone’s register interval. Maybe the connection times on small interval delays.
Changed it, without any luck.
Sometimes the best way to discover a voip problem is run the syslog on the Anynode-device and after reboot watch the entry… this way help me the most in my scenario. VoIP devices generally not have logs but a syslog they are almost all (in Poland market).
Since you haven’t shown the filter condition you used when sniffing the traffic on the Mikrotik, it is not clear whether the Mikrotik indeed doesn’t forward the INVITEs to the AnyNode or whether it does but they got somehow lost on their way there.
If the SIP helper is disabled, Mikrotik doesn’t inspect the SIP payload, so it treats the INVITEs just like any other UDP packets, i.e. the L4 contents of the packets should play no role.
If the IP of the registrar is the same like the source IP of the INVITEs, which should be the case, you do not need a dst-nat rule for the INVITEs to be redirected from the WAN IP of the Mikrotik to the LAN IP of the AnyNode, as the UDP packets carrying those INVITEs are considered response packets in the connection created by the first REGISTER.
So first, I’d like to see what /tool sniffer quick ip-address=5…101 (the address of the PBX, not writing it in full as you took the effort to hide it in the OP) shows when you make the incoming call attempt (INVITEs from the PBX address towards your WAN). Normally, you should see the packet on the WAN interface with the 217… as destination address, and then once again on the LAN interface, with the IP address of the AnyNode as the destination one. If this is not the case, something is rotten with the routing on the Mikrotik, but according to the configuration export you’ve posted, the only external causes I can imagine are a failure to obtain the MAC address of the AnyNode, or some MTU issue on the LAN if the INVITE is huge and the MTU of the LAN on the Mikrotik is higher than the actual one of the AnyNode. Which reminds me of a case where a default configuration of some Mikrotik model/CPU architecture had a MTU of 1600 or so on the bridge, and the symptoms were similar, except that the INVITE was coming encrypted in an IPsec transport packet as it was a VoWiFi scenario.
Also, your configuration export doesn’t match the connection state - the connection you have shown is fasttracked but there is no action=fasttrack rule in the export. Not that it would change anything as such, but maybe you have removed also some other “unrelated” configuration before posting the export?
Hi Sindy,
My sniffer was configured like this:
I’ve used your sniffer-rule, but I have the same result. Only SIP INVITES to ourpublic-ip, and not to the anynode.
Our firewall has the default config loaded for now, with some extra rules. We’ve used the basic config for this routerboard.
The reason why I’ve suggested to filter on the PBX IP address rather that on SIP port was that if the router was eventually sending some ICMP feedback, your filter would not capture it.
When you let the sniffer run for more than 3 minutes, so that a re-registration could take place, can you see the registrar responses (200 and possibly 401/407) to be sent to the anynode address?
what is the Ethernet size of the received INVITEs, and what is the actual-mtu value of the bridge interface of the Mikrotik?
Here’s the trace
Yes, register en re-register is working. The anynode SBC is also registered to our PBX.
Actual MTU = 1500, Size of the received invite is 1161 bytes
Maybe overly simplifying it, but if the device can register, but cannot receive calls, sounds like the PBX cannot reach the endpoint device on port 5060. Open that port up to the device and I’ll bet it works.
The trace shows that the router does not just drop the INVITEs but it notifies the sender about an issue with them. To confirm that, look inside the ICMP “deatination unreachable” packets, you should see the beginning of the INVITE packets there, at least the IP and UDP headers.
It seems as if their destination address was not the router’s WAN address but nevertheless they did arrive to it. Could it be that the AnyNode determines some other public IP using e.g. STUN, sends the determined public IP in the Contact field of the register, and the PBX uses that other public address from Contact rather than the one from which the REGISTER has actually arrived to it? The Mikrotik configuration doesn’t suggest that, but maybe there are some more routers there?
I would have to see the actual capture file to say more, with both the REGISTER exchange and the INVITE, to say something more specific.
Guess I should have said forward that port.
It is already open by way of the connection tracking shown in post #5.
Getting ICMP host unreachable responses points to something more complex, hence the requests to see a packet trace of the registration process.