I have two lans separated by two bridges and a block of 5 public IP’s. Whenever I add my src-nat to forward all outgoing traffic to another IP for the second lan I start to get packet loss from the router. Any suggestions on how to diagnose what is going on? I have ready every tutorial on the internet and my config appears to be correct.
Any suggestions are greatly appreciated.
Thanks.
Your srcnat chain should look something like this:
out-interface=wan src-address=ip.of.lan.a/24 action=src-nat to-address=a.a.a.a (use the correct LAN netmask if /24 is not correct, and a.a.a.a = public IP for LAN A)
out-interface=wan src-address=ip.of.lan.b/24 action=src-nat to-address=b.b.b.b
out-interface=wan action=masquerade (this is a default in case you ever add/remove other lans and forget to add them with specific src IPs)
You also need to let the Mikrotik know that it’s got these extra IP addresses a.a.a.a and b.b.b.b on its WAN interface.
My preferred method would be to set arp=proxy-arp on the WAN interface, and then add blackhole routes for a.a.a.a/32 and b.b.b.b/32 - this way, the Mikrotik will respond to ARPs for those addresses, but it will still consider its original WAN addresses as different from these other two IPs.
Thank you for the response.
Could you give me an example of proxy-arp with the WAN.
I attempted to set ether1 as proxy-arp and configured a route for my additional IP addresses. While I don't get packet loss with this setup, I am unsure how to configure my inbound and outbound NAT.
Also I have been unable to ping any IP except the first in my block of 5 from outside the network with either setup. Is this normal?
We have used the SRC-NAT setup with other providers without issue so I am a little lost.
Thanks again for your time.
In my experience, proxy arp is only unreliable if the target IP is moving between multiple devices doing proxy-arp. If there is only one device consistently between the network and the target IP, then there’s no problem. Your ISP is grasping at straws there.
If you have any kind of load balancing or primary/backup Internet connection settings in your router, this could be the source of the packet loss - try disabling such rules.
As far as the nuts and bolts of the configuration I recommended, these are the moving parts:
set wan interface to arp=proxy-arp (enables proxy arp)
black hole routes for the extra IPs: Tells the Mikrotik that these addresses live in some direction other than the WAN interface. This causes it to reply to arp requests for those IPs when they’re received on the WAN interface.
You can’t ping those extra IPs because they don’t actually live anywhere. This is to be expected. If you want them to ping as well, then instead of the proxy-arp and black hole route method, you could just add the extra addresses to your WAN interface.
So if you have 192.0.2.32/29 as a range of public IPs, with the default GW being 192.0.2.33, you could add three addresses to ether1 (if ether1 is the WAN):
/ip address add address=192.0.2.33/29 interface=ether1
/ip address add address=192.0.2.34/29 interface=ether1
/ip address add address=192.0.2.35/29 interface=ether1
This essentially does the same thing, but now all three IPs are actually assigned to the Mikrotik, so it will now reply to any incoming requests to those addresses, so long as the firewall filter rules permit it.
As for the NAT rules, when you apply a src-nat rule, this is a stateful rule which will cause outbound packets to have their src-address re-written by the Mikrotik. If the packet’s source was originally 192.168.2.107, it will continue upstream with that being changed to e.g.: 192.0.2.35 - the Internet will route the replies back to this IP, and the Mikrotik will check its connections table to find out which internal host should actually get the packet. It will eventually find the combination of remote IP + src/dst port numbers matching the request made by 192.168.2.107 and automatically re-write the DESTINATION IP of the reply packet so that it will now forward to the correct inside host. If a packet comes from the Internet with a dst=192.0.2.35, but from an IP address / port number combination that has not been seen before, the router will not do any NAT. At this point, it must process the packet “normally” - in which case there is a black hole route for the IP (using the proxy-arp method). This means that the packet will just get discarded. If you used the “multiple IP address” method, then these packets won’t get discarded, but will be considered as talking to the Mikrotik itself. In this case, if the packet is a ping request, the Mikrotik will reply; if it’s a Winbox packet, the Mikrotik will let the connection proceed. (again, assuming the input chain of your firewall permits the connections)
After trying both solutions and getting the same results I started digging. I found that WOW enabled a feature called “cable source verify” on the CMTS to which I am connected. This helpful feature supposedly makes IP hijacking harder by enforcing a 1:1 relationship between customer MAC addresses and customer IP addresses at the CMTS (a.k.a. the provider-side cable modem). That 1:1 ARP map makes total sense for links carrying dynamically allocated single IPs or single static IPs.
Any other suggestions are appreciated as we are considering a different provider at this point.
You should complain to them enough to get them to disable it on your connection or else get them to static route a /29 to your WAN IP. It’s very common for one device to use multiple IP addresses on its WAN interface. I can understand why the measure is in place on a general broadband access segment, but if you explain your situation to them, then they should lift the restriction on your circuit.