We have an RB 1100 with ROS 5.25. The config in question has 5 static address on ETH1 which is our external interface. Configuration is x.x.x.36 to .40/24.
At one point all addresses were pingable and worked. After a power outage, only the lowest number–.36 is usable and pingable. A downgrade was performed which yielded use of one more address then another power failure after which again only the lowest number address was usable. I am completely baffled. I did find that occasionaly enabling then disable the addresses will sometimes bring the addresses live again. I would love to hear thoughts on this.
I’ve reordered the IP addresses to make it easier to parse in my head.
It’s unfortunate that your copy and paste truncated some of the lines, but I think we can figure out what is necessary. BTW, your configuration shows 6 IPs on ether1. There may have been a typo in your first post which said 5 IPs
Personally, I would set the prefix length of y.y.y.37-41 to /32; leaving y.y.y.36 with its /24 prefix length. It may not be required on MikroTik, but it probably won’t hurt. It has been required on some other systems I have used over the years.
Do you really not have any /ip firewall filter or /ip firewall mangle or /ip firewall address-list in your configuration?
I’ve reordered the two disabled NAT dst-nat rules to after the masquarade rule to make it easier for my brain to deal with. I also removed the line wrap.
From where are you pinging; from outside ether1, or from behind one of the other interfaces on the RB1100?
I don’t see anything “wrong” with the config you gave us. But if you didn’t give us the filter/masquerade/address-list parts, we are still blind.
Does “/system routerboard print” and / or “/system routerboard settings print” give you any blank fields or errors? My thinking is that it might be possible that the firmware was corrupted so didn’t load and you are running on top of the backup bootloader firmware which could be really old and buggy. I don’t know that would cause any issues. That is just me making a wild guess after not seeing a problem with the config you showed us.
Another wild idea: I also just want to confirm that the prefix length is supposed to be /24 rather than /29. It is acceptable to do it either way, but if it is supposed be a /29, your default gateway would probably be y.y.y.33 and you would be using the five IPs from y.y.y.34-38. Having the wrong prefix length and using some of the wrong IPs might cause some issues like you are reporting. The upstreams gear might have previously been configured more ambiguously and permitted the incorrect configuration on your end.
You are probably correct, but while I am grasping at straws, I thought I would try for more than one.
Thank you for your input Lambert. /system routerboard print and /system routerboard settings print do not yield errors. I am pinging from the outside in however when 1 to 1 NAT is configured the inet connection fails to the associated internal host as well. I am thinking firmware corruption, but as a newb to router os I am not sure how to deal with that. I have tried both downgrading and upgrading the os. In one instance, this process yielded positive results in that where an address was not functioning it started to of course only up to when a power failure occurred again then failed. I am aware that one can use the reset function but does this only reset the configuration? Having said that if it is corruption how would one “wipe” it then reload if you will? Thanks a bunch for your help.
reset only helps if you are stumped by the configuration and do not see what could be wrong.
If you are not sure about some feature, it is better to try it out first on test setup or in a simpler environment.
If in NAT this is all what you have, there should not be a reason why to reset whole thing, just start from simple configuration, like - masquerade everything, then add additional NAT rules for packet forwarding. Then attempt to add additional rules for 1 to 1 nat.
Note that in NAT rules work in same way as in everywhere in firewall, that is first rule in chain that gets the packet, works with it, so make sure that specific src-nat rules are before main masquerade rule since you can set to what address mask source while masquerade will select one of addresses and use it.