NAT Mapping for SIP Devices

RouterOS General
1

We have an office with two VOIP devices, a Cisco SPA942 and a Linksys PAP2, behind an RB951G running v5.24. Both devices are able to get provisioned over port 80 but are failing to register over ports 5060 & 5061. What we are noticing in the firewall connections window is that the devices are not using random source ports for the communication but are both trying to use port 5060 or 5061. This is occurring whether the SIP service port is enabled or disabled. NAT keep-alives are enabled on the VOIP devices, but NAT mapping is not, though we have tried enabling it without any success. Why isn’t the NAT mapping working properly on the MikroTik?

Thanks.

2

The connections tab shows the original non-NATed IP/port so presumably the devices are using whichever ports they have been set to use. Do you have SIP logs showing the attempt? If you Torch the external interface do you see bidirectional traffic on the SIP ports?

3

If I Torch the external interface for SIP port traffic, there is only a Tx Rate, no Rx Rate. So it would seem the SIP traffic is not bi-directional.

Thanks.

4

OK - but can you see that the IP traffic has been src NATed outbound? If there is no return traffic at all then it sounds as if the target host is never responding.

5

I’ve attached screen shots of the Firewall-Connections screen and the Torch results. Do these help you understand what is happening?

Thanks.
torch.png
connections.png

6

If possible I suggest that you check if these phones register when connected via some other connection. There appears to be no return traffic from the SIP server. It would be useful to know if they register when connected elsewhere in case the problem is not RouterOS related.

7

That has been tested. Both devices have been taken to another network and both provision, register, and work perfectly.

8

Have another look with torch and show the IP numbers. Perhaps there is something wrong with the traffic leaving such that it cannot be returned by the SIP server.

9

New Torch screenshots attached.
External_Torch.png
Internal_Torch.png

10

Have a look without the 3 second timeout - try say 30/60 seconds. It still looks as if there is no return traffic from the SIP server.

11

Post your firewall rules. /ip firewall filter print

My guess is there is a default drop rule in there somewhere.

Jason

12

There is no change if I increase the Torch timeout to 60 seconds - the same connections appear. This issue only started occurring after we switched the firewall at the office. Previously, they were using a Netgear ProSafe which was also NATing, and the VOIP devices did not have any trouble behind that firewall. Now with the MikroTik we have this really irritating issue. :angry:

13

Here are the firewall rules:

Flags: X - disabled, I - invalid, D - dynamic 
 0   ;;; Accept established connection packets
     chain=input action=accept connection-state=established 

 1   ;;; Accept related connection packets
     chain=input action=accept connection-state=related 

 2   ;;; Drop invalid packets
     chain=input action=drop connection-state=invalid 

 3   ;;; Allow access to router from core iPremise network
     chain=input action=accept src-address-list=safe-ips 

 4   ;;; detect and drop port scan connections
     chain=input action=drop protocol=tcp psd=21,3s,3,1 

 5   ;;; Suppress DoS attack
     chain=input action=tarpit protocol=tcp src-address-list=black_list connection-limit=3,32 

 6   ;;; Detect DoS attack
     chain=input action=add-src-to-address-list protocol=tcp address-list=black_list address-list-timeout=1d connection-limit=10,32 

 7   ;;; jump to chain ICMP
     chain=input action=jump jump-target=ICMP protocol=icmp 

 8   ;;; jump to chain services
     chain=input action=jump jump-target=services 

 9   ;;; Allow Broadcast Traffic
     chain=input action=accept dst-address-type=broadcast 

10   chain=input action=log log-prefix="Filter:" 

11   ;;; Drop everything else
     chain=input action=drop 

12   ;;; 0:0 and limit for 5pac/s
     chain=ICMP action=accept protocol=icmp icmp-options=0:0-255 limit=5,5 

13   ;;; 3:3 and limit for 5pac/s
     chain=ICMP action=accept protocol=icmp icmp-options=3:3 limit=5,5

 14   ;;; 3:4 and limit for 5pac/s
     chain=ICMP action=accept protocol=icmp icmp-options=3:4 limit=5,5 

15   ;;; 8:0 and limit for 5pac/s
     chain=ICMP action=accept protocol=icmp icmp-options=8:0-255 limit=5,5 

16   ;;; 11:0 and limit for 5pac/s
     chain=ICMP action=accept protocol=icmp icmp-options=11:0-255 limit=5,5 

17   ;;; Drop everything else
     chain=ICMP action=drop protocol=icmp 

18   ;;; accept localhost
     chain=services action=accept dst-address=127.0.0.1 src-address-list=127.0.0.1 

19   ;;; Allow SNMP
     chain=services action=accept protocol=tcp dst-port=161 

20   ;;; allow DNS request
     chain=services action=accept protocol=tcp src-address=172.20.103.0/24 dst-port=53 

21   ;;; Allow DNS request
     chain=services action=accept protocol=udp src-address=172.20.103.0/24 dst-port=53 

22   ;;; IPSec VPN
     chain=services action=accept protocol=udp dst-port=500,4500,1701 

23   ;;; IPSec VPN
     chain=services action=accept protocol=ipsec-esp 

24   chain=services action=return
14

Nothing? Nobody has any idea why this is occurring? It does not make sense for the issue to be upstream since there was previously a NATing firewall that did not cause any problems.

Any further help would be greatly appreciated.

15

If you are getting no return traffic from the SIP server then it is entirely possible that it doesn’t like something but the inbound traffic that it is seeing. It is hard to get a full picture from the screenshots.

Incidentally your firewall rules show no filters on the forward chain which is not causing this problem but which is a security concern.

16

may be need configure SIP server?

sorry if

and i swith off ip firewall services sip