We have a few customers that have two DSL lines. One for VoIP and one for everything else. This gives better voice quality.
The problem is that the masquerade rule on the VoIP PPPoE client interface should set the source IP to the IP that’s on that interface. Instead we’re seeing a lot of traffic going out over the VoIP interface with the Internet/Data interface’s source IP! This means the ISP VoIP hardware replies back to the wrong IP/interface.
Here’s more detail about the config:
/interface pppoe-client pr
Flags: X - disabled, R - running
0 R name=“pppoe-ADSL” max-mtu=1480 max-mru=1480 mrru=disabled interface=ether1-WAN user=“hidden” password=“hidden” profile=default service-name=“” ac-name=“” add-default-route=yes dial-on-demand=no use-peer-dns=yes allow=pap,chap,mschap1,mschap2
/ip firewall nat
add action=masquerade chain=srcnat comment=“MASQ: To ADSL” disabled=no out-interface=pppoe-ADSL
add action=masquerade chain=srcnat comment=“MASQ: to VoIP-ADSL” disabled=no out-interface=pppoe-VoIP
And then I have this static route for traffic to our VoIP server (196.25.1.1 are used as an example) to route through “pppoe-VoIP” instead of the default gateway:
Going by the information you posted that would be a bug. Masquerade should always translate to the IP on the interface traffic is leaving through. If you have verified that traffic is actually going out the VoIP interface as you intend it to (routing is working, basically) I’d send this into support@mikrotik.com as a bug report and see what they say. The community cannot help with bugs.
This is not always true. Masq looks at the interface its leaving on when the connection first starts. If the routes change mid way thru the traffic will still be natted to the original IP but leave on whatever route is available. Routing and natting are COMPLETELY separate processes.
The SIP helper sometimes makes things worse … : )
You may have to write a script to delete connections when the route isnt available anymore to clear out the NAT tracking on those connections.
True, I was assuming that traffic stayed stable on one interface and that the initial packet of the connection (the one that establishes the connection and that all future NAT is based on) shows the wrong IP. That may have been a faulty assumption.
I know SIP headers include the SRC ADDRESS, but we’re using IAX2 and not SIP. As far as I know IAX2 peers reply on the actual source address and not to any IP/Hostname in the packets itself.
So we’re using Masquerade (and tried src-nat specifying source IP to use) on the VoIP only PPPoE interface. The VoIP only interface is not the default route, so we set our outside voip server’s IP as a static route to route through VoIP only PPPoE interface instead of the default PPPoE interface.
Am I missing something? Does IAX also have the source IP, that replies should be sent to, in the VoIP header packets somewhere?
Routing over multiple ISPs. If there is an established TCP/UDP connection and then an ISP fails, we properly route out the other ISP, but the connections stay in the table and show the old ISP IP public address as the “Reply Dst. Address”.
In the attached screenshot, you can see the “Reply Dst. Address” is the IP of the failed ISP.
Hi,
Were you ever able to resolve this issue?
I am running ROS 6.26 and I seem to have the same Issue.
I have the following config ona RB951G:
eth1 = Connection to a router from an ISP with Static IPs. Using a SRC-NAT with the static IP and working.
eth2 = Connection to an ADSL router in Bridgded mode.
eth5 = LAN connection to my LAN.
PPPoE1 = ISP for data. Interface = eth2. It get’s a dynamic IP. SRC-NAT with MASQ for all traffic going out this connection.
PPPoE2 = VOIP conneciton. Interface = eth2. Gets a Dynamic IP. SRC-NAT with MASQ for all traffic going out this interface (nothing seems to hit this NAT rule)
When I reboot the RB, it seems to use one of the IPs at “random” to Masquerade with. I have rebooted 3 times and 3 different IPs were used. Once the eth1, once the PPPoE1 and once the PPPoE2. All traffic through all interface uses the same MASQ IP.
I added firewall rules to log the traffic for all packets going to my VOIP SIP Provider IP and it logs that the Internal PABX IP is NATted to the PPPoE1 IP for instance. It is supposed to NAT/MASQ using the PPPoE2 Ip. But the traffic doesn’t seem to hit the MASQ rule.
If I disconnect the PPPoE1 Connection the IP is no longer on the RB, but hte Firewall rule shows that the MASQ that is taking place still has that IP. So it seems to be “caching” the IP for the MASQ rules.
I also tried disabling all MASQ rules under NAT and the Packets are still showing the NAT (IP:5060 → IP:5060) entries.
Unfortunately I can’t post my entire firewall rules here, i am just trying to get some idea what else to try.
EDIT: 2015-03-02
I have found my issue, but don’t really have a good solution yet.
There is a static route for my VOIP provider. on a RB reboot, the PABX is trying to make a connection to the SIP provider and the traffic is routed through the default route. The connection tracking picks up it is a SIP connection and keeps the connection in the list. Once the VOIP PPPoE connection is up, the connection through the Default route (eth1) is still remembered and refreshed every couple of minutes. If I manually delete this connection (that is not live since it can’t really get to the VOIP provider), the next attempt routes through the static route and then everything comes up normally.
I’am having a similar problem with one installation
ether1 LAN
ether5 WAN (cable)
ether6 WAN (DSL, VoIP only)
Default route points to ether5, a specific /19 route for the SIP provider points to ether6 gateway. The routing itself seems to be working fine.
I also did a masquerading for each interface, but packets going out on ether6 getting the IP as source which was assigned to ether5. SIP helper is disabled, but the result is the same.
Traffic is initiated by the PBX (LAN) to the SIP provider, no other conflicting connections are there.
I’am somewhat lost, is this a bug, because my config is pretty simple?
