Everything that you are looking to do is fairly easy and straightforward. Here are the basic steps that will get you started and most of the way there.

Code: Select all

/ip firewall nat
add action=dst-nat chain=dstnat dst-address=13.14.15.18 to-address=10.0.19.50
add action=src-nat chain=srcnat src-address=10.0.19.50 to-address=13.14.15.18

You also want to NAT out everything else out of .22. Also setup your SSH forwarding and others in the dstnat chain like above.

Code: Select all

/ip firewall nat
add action=src-nat chain=srcnat src-address=10.0.16.0/21 to-address=13.14.15.22
add action=dst-nat chain=dstnat dst-address=13.14.15.19 protocol=tcp dst-port=22 to-address=10.0.17.30
add action=dst-nat chain=dstnat dst-address=13.14.15.19 protocol=tcp dst-port=80 to-address=10.0.19.48
.....

add action=src-nat chain=srcnat src-address=10.0.19.50 to-address=13.14.15.18

Please post your firewall rules with then with "/ip firewall export". If the rules aren't firing and incrementing there are a few potential causes.

The first most likely one is that there is a rule further up the chain that is already matching them, so they never reach the more specific rule for the PBX. Remember, firewall rules are processed in order, so their placement in the chain is very important. Once a packet matches one rule, it is not processed by other rules within that chain.

The second potential is that your firewall rule is too narrow so it is missing what you want, not likely based off of what you said.

The last option is that there is a filter rule that is explicitly blocking/dropping those packets. Depending on your expected behavior and where your rules are this could be the problem.
http://wiki.mikrotik.com/wiki/Packet_Flow#Diagram

/ip firewall connection tracking
set enabled=yes generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s tcp-close-wait-timeout=10s tcp-established-timeout=1d tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s \
    tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-syncookie=no tcp-time-wait-timeout=10s udp-stream-timeout=3m udp-timeout=10s
/ip firewall nat
add action=dst-nat chain=dstnat disabled=no dst-address=13.14.15.19 to-addresses=10.0.19.50
add action=src-nat chain=srcnat disabled=no src-address=13.14.15.19 to-addresses=10.0.19.50
add action=dst-nat chain=dstnat disabled=no dst-address=13.14.15.20 dst-port=22 protocol=tcp to-addresses=10.0.17.30
add action=src-nat chain=srcnat disabled=no src-address=10.0.16.0/21 to-addresses=13.14.15.22
/ip firewall service-port
set ftp disabled=yes ports=21
set tftp disabled=yes ports=69
set irc disabled=yes ports=6667
set h323 disabled=yes
set sip disabled=yes ports=5060,5061 sip-direct-media=yes
set pptp disabled=yes

SRC and DST nat are different chains and processed at different times, so they don't effect each other with order. Your src-nat rule is messed up for the PBX. You want to src-nat the private IP address of the PBX out of a public IP, this means your src-address needs to be the private IP address of the PBX, and the to-address needs to be the public IP you want to send it out of.

add action=dst-nat chain=dstnat disabled=no dst-address=13.14.15.19 to-addresses=10.0.19.50
add action=src-nat chain=srcnat disabled=no src-address=10.0.19.50 to-addresses=13.14.15.19
add action=dst-nat chain=dstnat disabled=no dst-address=13.14.15.20 dst-port=22 protocol=tcp to-addresses=10.0.17.30
add action=src-nat chain=srcnat disabled=no src-address=10.0.16.0/21 to-addresses=13.14.15.22

What IP addresses do you have assigned to the WAN interface of the router? You need to have any IP address that you want to NAT out of or forward for assigned to the router. If you don't have the address assigned it won't know to listen on that address.

What IP addresses do you have assigned to the WAN interface of the router? You need to have any IP address that you want to NAT out of or forward for assigned to the router. If you don't have the address assigned it won't know to listen on that address.

All of them (.18-.22) although my gut says don't assign anything but .18 (for the router), use iptables prerouting chain to make them available before the nat chains run (which is post-prerouting and pre-forward/input chains).

You don't need to touch anything in mangle at all for an IP address to work. Mangle is used for policy based routing functions, and QoS mainly. Only if you had multiple routing tables setup like in a failover or load balancing situation would you need it. And the only reason why you would need it then is to mark packets coming in on one connection so the router remember to send packets back on another connection.

If it's not responding to anything other than .18, what you can do is run torch on your WAN interface to see if the traffic is even getting there. That is a tool built into RouterOS. The only thing that is basically left at this point is your ISP. You can try restarting your modem from them to see if that helps and clears the ARP table, if not then you will need to call them. Some ISPs have problems giving out multiple IP addresses to the same MAC address.

Like I said, you can use the torch tools to see what is going on with traffic. This will tell you what is going on, it may not be able to give you as much information as wireshark, but you don't need that level of information. You don't need explicit accept rules unless you have a catch all drop rule, or if you are seeing if the filter is incrementing for that specific traffic.

What you need to see is the incoming connections, since you know what IP they are coming from and going to, you can narrow it down to only watch for those connections. First watch the WAN interface and see what traffic comes in from that IP. You will see if the router is receiving and transmitting. If it's receiving and not transmitting, then something is going on on the LAN of the router, and if it is receiving and transmitting then there is likely something up stream going on. Look at the LAN interface to the PBX and see if the router is sending and receiving traffic from that. If it is sending, but not receiving then the PBX is not doing something, if it is sending and receiving traffic, then there is something in the 1100 happening. Basically look at each stage of the connection with the torch tool and narrow down where the issue is happening.

We forward UDP all the time, while SIP is more sensitive to NAT, having one-to-one NAT setup usually solves any of those problems.

I'm glad it's working, though the problems that randomly fix themselves are the most annoying ones to deal with.

The answer to your question has to do with ARP and the traffic getting to the input interface before it can even get to pre/postrouting. When your upstream provider routes one of the IP addresses to you, if it doesn't have an ARP entry in it's table for that IP address, it will send out a broadcast on the subnet and ask who owns that IP. If the router doesn't have that IP assigned to it, it will not reply to that saying it owns it and will therefore never get the traffic to dst-nat to the appropriate location. Similarly if it doesn't have the appropriate IP address assigned to it when doing a src-nat how can it use an address it doesn't own, and when the return traffic gets back, how can it accept traffic for an address it doesn't own?
http://wiki.mikrotik.com/wiki/Packet_Flow#Diagram