Hi guys,

Thanks for taking the time to open this post. I don't post very often, and I usually keep trying and testing until I get something working, but I think I might have hit a wall ( or a bug in the routerOS SIP helper perhaps ).

One of our customers has a simple network with two connections :
A) ADSL2 connection with static IP 58.xxx.xxx.126
B) Fixed Business Wireless connection with static IP 202.xxx.xxx.214

Both connections work. They both have public IP addresses.
If we set the default gateway ( 0.0.0.0/0 ) to use A), then everything works ( including VoIP )
If we set the default gateway ( 0.0.0.0/0 ) to use B), then everything works ( including VoIP )

The customer would like to use the A) connection for their VoIP traffic, and their B) connection for VPN traffic and other internet traffic. So , we setup a mangle rule that will routing mark traffic to the VoIP (SIP) server : edit : I just realize there's not much point in using the routing mark on incoming traffic from the VoIP provider - rule 1) ...

Their Asterisk VoIP server has IP 10.1.1.250 and their SIP provider has IP 202.xxx.xxx.10. ( I have removed the particular IP addresses of this customer )
By setting these mangle rules, the VoIP traffic is correctly being marked ( when making a call, I see the numbers go up ).

So that's step 1 done, works well. So Step 2 would be to route traffic with the "adsl" routing-mark over the other gateway. ( I have removed some useless information like active VPN connections )
58.xxx.xxx.126 is their ADSL connection.
202.xxx.xxx.0/27 is the VoIP provider's SIP server IP range.
202.xxx.xxx.213 is their wireless connection.
0.0.0.0/0 is the default route which is configured with a distance of 2 in the hopes that the distance 1 ( rule 0 ) would override this. I have tested with different distances. As you can see, rule 0 is DISABLED at this moment, because if I enable it, VoIP doesn't work. This is a live environment so I can only "test" during the weekends or late at night when noone is on the phone ).

So, when I configure it like this, and I enable rule 0, I can successfully ping from the Asterisk VoIP machine ( 10.1.1.250 ) to the VoIP provider's SIP server and it uses the separate ADSL route. So everything seems to be working correctly.

But, the SIP server won't connect (timeout). In the packet dump logs, I see that the router is trying to connect to the VoIP provider SIP server from IP address 202.xxx.xxx.214 ( their wireless provider ). Did I forget something ? Perhaps the Routing Lookup table in /ip route rule ? ... Any advice is very welcome.

I'm running RouterOS 4.6 on a RB450G platform, I have gone through the firmware release notes and see nothing related to SIP , so I see no reason to upgrade unless someone here advises to upgrade.

Cheers!

I have uploaded a screenshot of the error ( large file 5MB ) , including the packet trace and the error here :

http://www.hyperfileshare.com/d/747869a7


EDIT :

I have tested with a SSH route, and that works flawlessly. It seems this only happens with SIP traffic ?

Even more strange : If I change the route AFTER the connection is initially made, then the SIP traffic gets routed out of the ADSL interface correctly ??... so it seems it's just the initial packet which gets popped out the RIGHT interface, with the WRONG IP. This probably causes the upstream router to say "noway, you can't use bogus IP for sending out traffic" and drops the packet.

That's what I think, but I would very much hope that someone replies.

I will reply to my own post :

I have contacted Mikrotik support ( Maris ) and he has helped me solve the problem. The problem was that I had enabled the new route, but there was still an entry for that SRC nat in the Connections tab of the IP -> Firewall. In other words, connection tracking tracked the connection, and I changed the route but had to remove that connection from the tracking.

To solve the problem, I selected all the connections in the IP -> Firewall -> Connections and press the "-" to delete them all. After this, it worked !

Many thanks Maris from Mikrotik support !