not my first time around the block with RouterOS and have successfully configured quite a few Mikrotiks for small office use, but predominantly by using WinBox and starting out with base configurations (QuickSet). In the following case, an office is issued a range of static IPs by the ISPs (WAN) and internally (LAN) it is desired to use 192.168.1.xxx
LAN: 192.168.1.xxx /24 subnet
WAN: 77.42.220.xxx /29 subnet - issued range of 5 public IP addresses starting at 77.42.220.10 with gateway at 77.42.220.9
I have configured it (in a manner that has worked before in other sites), however, for the life of me I don’t understand why it is not routing for LAN devices:
I can ping the WAN interface successfully (ether1) from the wider internet (as well as access other services, such as ssh, winbox, etc). I can ping the mikrotik from within the LAN. The mikrotik itself makes requests that are routing to the wider internet (using the traceroute tool)…however, within the traceroute tool, if the LAN bridge interface is chosen it fails to route. No devices on the LAN in the respective subnet gets routed out. So, WTF is going on? What am I missing??
Will throughly appreciate anyone’s input on the above configuration.
there’s no scenario i can conceive in which this failure to route LAN devices through the WAN, with the current configuration makes any sense! Any other thoughts??
Falklan - it’s good practice? That’s how I’ve always done it? In order for the mikrotik itself, sitting on the same subnet as the LAN to be the gateway irrespective the the kind of infrastructure there is beyond it - without having to change LAN network details in the case of any WAN changes?
It’s been my understanding that that is the purpose of the static route - when packets arrive at the LAN interface (192.168.1.254) that are destined outside of the LAN subnet, then they should be routed to the gateway (77.42.220.9) - accessible via ether1 – the NATing works to masquerade those WAN-outgoing packets behind one IP, which is that assigned to the ether1 interface (77.42.220.13)
Regardless, on your tip/question I tested the 77.42.220.9 gateway on a client within the LAN, and it was successful - so that’s a good thing - but it’s not ideal should anything change with the WAN interface for LAN configuration to have to change on every client… even if clients obtain their TCP/IP/DNS settings via DHCP. Any thoughts??
falklan - take that back. it wasn’t successful - well not repeatable, at least. So I’m back to square one. A functioning WAN interface for the mikrotik. A functioning LAN interface. But no routing between them.
That’s part of my basic set of diagnosis tests… in short
pinging the WAN (77.42.220.13)…
…From the mikrotik: setting src-address for ping of 192.168.1.254 (ie. that of the LAN-facing interface on the mikrotik) - SUCCESS
…further pinging the wider internet (by IP address and fqdn) SUCCESS
…however, from any device on the LAN (with correct tcp/ip settings) pinging mikrotik LAN interface at 192.1.254 SUCCESS
…whereas pinging the WAN interface at 77.42.220.13 (or beyond, by IP) FAIL
…further all DNS resolution FAIL
The mikrotik itself is able to ping hosts on the wider internet successfully from its WAN interface numerically and by FQDN (thus, DNS resolution is working)
Why do you have horizon=1 on the bridge port configuration?
That may possibly be part of the issue…
plus I agree with Paternot’s suggestion to use interface-based NAT decisions. Although what you did shouldn’t matter one iota as far as functionality goes.
@ZeroByte and Paternot - i had tried all permutations of your suggestions to no avail. Also, unset horizon as I agree it isn’t really relevant.
Regardless - i still have the same behavior - the router itself sees both WAN-going and LAN-going (from the respective interfaces) AND its LAN interface routes successfully through the WAN - but no devices in the LAN are routed beyond the mikrotik’s LAN ip
That sounds like the culprit - it’d have the exact effects seen. I notice your post was marked with the new “accept as answer” checkbox (love that feature btw)
I’ve discovered that once I ping devices in the LAN (from the mikrotik) that have already been leased/assigned an IP address by the DHCP server (also from the mikrotik) – 4 or 5 pings in are timeouts, then it starts to ping successfully - THEREAFTER the device on the LAN is finally routed properly through the mikrotik!
It doesn’t matter how long the ip address has already been assigned - it won’t work unless I do the above from the mikrotik.
All are various flavors of windows and internet-connected devices (printers, and so forth)
This doesn’t get any crazier and for obvious reasons isn’t practical for a rollout to have to ping every single device… regardless does this provide any insights??
What’s your network’s internal layer2 infrastructure like?
I’d start connecting some devices directly to the Mikrotik to see if the problem persists - perhaps even with the LAN disconnected in order to rule out any strange stuff that might be happening within your broadcast domain.
