I have a Mikrotik 2011UiAS running as the primary router for my home network.
One of the physical ports is defined as the exit port to the internet provider,
the others are bridged and connected to the devices of my local network.
There is another port not connected to the bridge.
While the main local network (192.168.88.0/24) works fine, the single port makes some problems:
There is also a dhcp server running on that port. When physically connected to that port,
the dhcp server gives out leases. Also the router is able to ping the client.
BUT the client is not able to use the internet.
To be sure that there is no misconfiguration with filter rules and bridge filters they all have
been deleted for testing purpose.
It is also interesting while using the tools/torch utility I found out, that the packets from
the client connected to the single port are forwarded and masqueraded so that they
are leaving the default gateway with the source address and the right
destination ip <8.8.8.8>. Also there are packets replied with the right source
<8.8.8.8> and destination .
BUT they never reach the client! It looks like all these packets, comming back,
are not masquerade the way back or lost at any other point.
Using wireshark on the client shows that ICMP packets getting no reply.
You imply that traffic connected to the bridge do work, but only this one non-bridge port is not working. Carefully compare the rules and settings for the working ports and the non-working port. I’ll bet you find something that is different and preventing. If that does not help, I would also suggest that you export your entire IP configuration and post it here so we can better help you.
What’s the idea behind posted srcnat rule? Because unless there’s another srcnat rule before this one that matches traffic from 10.x network, this one will set source to 10.10.10.1 and not .
I have also tested a clean installation of routeros by the time. It looks like a bug.
@k6ccc: The only difference between the working bridge and the single port is that the single port is actually a vlan.
Again, there is a dhcp-server running on the vlan. Leases are working fine. Connectivity between the client and
the router (ping, http) is now working 100%. The only problem is the connection to the internet.
Vlan network is 10.10.10.0/24, router network is 192.168.88.0/24. The problem must be the translation! Really,
all checked twice. Packets are being forwarded to the ETH1-gateway fine, but replies from the outside are not
being forwared to the vlan. It looks like the masquerading rule from above is only working for the bridge network
and only works one-direction for the vlan?
you should not use the to-address in this statement as that changes the source ip you want to use dst-addres as this specifies the address you trying to reach. hope that makes sense for more info refer to the wiki http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT
After spending the whole day searching for the problem I found the problem eventually:
After three years of using the router and some extensive configuration-upgrades
including firmware / software-updates there was a “configuration error” in the
/ip firewall nat area. After /export file=foo and system configuration reset
I reimported the configuration file and now everything works as it should.
I was also able to find the problem and correct it directly by simply deleting all
/ip firewall nat rules and adding them manually again.
was not correct because of the “to-addresses=0.0.0.0”-part. There is a bug in the web-gui! If you set-up a new
rule like this with action=srcnat, enter a to-addresses, save it and later remove the “to-addresses=0.0.0.0”-part and
change it to “action=masquerade” there will be the “to-addresses=0.0.0.0”-part left in the system. You cannot delete
it besides deleting and recreating the whole rule.
