Morning all.
First, i have turned off the SIP helper in the firewall settings… it dident help…
I have a Cloud Core Router connected to a single WAN connection. There are 3 networks:
192.168.42.x (LAN for normal users)
192.168.99.x (guest network, only for wifi)
192.168.0.x (phone network)
ports 5060, 6000, 5003, 5090, 9000, 9001 and 30000-30031 are all pointing at our VoIP box (Samsung something or other). these where the ports that where forwarded on our old (useless) Netgear box.
Anyway, after sticking in the CCR, outgoing calls are working, but incoming, not so much. Watching the traffic and firewall logs, i can see a request coming from our VoIP provider on port 5060 hitting the CCR and being transfered to the VoIP box, but then a request from that box to the firewall (192.168.0.1) on port 6000 is made… and gets dropped…
Now, i have no idea why its going to 0.1, and not the provider… any ideas whats going on here? It seems the reply header is sending back the MikroTik IP, and when the PBX makes a reply, its getting hit with the firewall hammer… Ive been at this 4 times and all late nights! i keep having to pull the CCR out and sticking back in the NetGear, which is pretty poor…
Thanks.
–Tiernan
Hello my friend ,
I think it’s about firewall chain you are using
input,output,forward
and maybe it’s better to use stateful firewalling and use proper chain
I’m not sure I get what you mean… There is a firewall rule allowing 5060 on the forward chain, but we don’t have nothing else. There is also a Nat rule for the incoming ports. Can you clarify what needs to be done?
Thanks.
It’s better to send your network diagram
Right. i dont have a diagram, as such, but here is an outline
WAN Link from ISP (192.168.13.xxx address) => ETH1 Port on CCR
ETH2 => LAN connection (192.168.42.xxx address range, DHCP and DNS provided my Windows DNS and DHCP, AD running on domain)
ETH11 => Phones network (192.168.0.xxx address, dhcp and dns managed by Router OS)
ETH12 => Guest Network (192.168.99.xxx address, dhcp and dns managed by Router OS)
There are NAT rules for 5060, 5090, 6000, 30000-30031 pointing at the PBX, all copied from our existing Netgear router.
There is also a route allowing traffic from the LAN network to the Phones network as some users have desk phone applications on their laptops.
all networks allow NAT rules out, so all traffic to the WAN is allowed back out.
It seems, after looking at the traffic logs and firewall logs, as mentioned above, that when the PBX is trying to get back out, it is making a call to the router on port 6000, not the voip provider. The image below i think shows the issue: https://www.dropbox.com/s/952apis5fvble27/VOIP-Packet.PNG?dl=0
If you see in that image, the source and destination are “correct” but the reply source and reply destination are, i think, causing the problems…
Thanks.
Have you tried turning SIP ALG off in IP/firewall/service ports? Just disable the ‘sip’ entry on port 5060.
@pants6000 that was the first thing i tried… outgoing calls work perfectly… its just incoming.
Can you get a packet capture of this happening for us to ogle?
no packet capture at the moment, but if you have a look here: https://www.dropbox.com/s/952apis5fvble27/VOIP-Packet.PNG?dl=0 you can see some of whats happening…
The phones are a business necessary, so doing this during the week is a problem. I will try get it done this weekend and get a capture for you then.
–Tiernan
Your ISP (or modem?) is giving you an RFC1918 “fake” IP, which is icky at best. I wonder if something upstream if you is at fault here… any chance of getting a real IP on your 'tik?
@pants6000 nope… our ISP use Mikrotik gear, and have it NAT mapped… its the modem that is giving us that address. This worked perfectly before on the (crappy) netgear router we currently have… We are currently looking at changing ISPs, but ideally we want this working first…
Well, let’s see what that capture looks like when you can get one… and us seeing as much of “/ip firewall export” as you’re comfortable with may be helpful as well.
So, its been a while… still cant get a capture during office hours and have had other things ive been trying to sort out… We are, however, changing ISP and phone provider… hopefully this issue will go away when that happens… fingers crossed!
