thank you for replay
but my problem is different
i don’t have any static IP to dst-nat, only provider have IPs and give us with his dhcp server
my question exactly is how can i do the dst-nat for my webserver without knowing the public ip?
This is exactly the situation that you have - provider givers you dynamic IP address. So you have to run a script which will check what ip address is set on interface by dhcp server and then script will set that ip address in nat rules.
i explain my situation more and write exactly command that i use
ether1=connect to lan
ether2,3,4=dhcp-client
ether2=ip2,gw2 ether3=ip3,gw3 ether4=ip4,gw4
MikroTik say to me :" Could not add new dhcp client- dhcp-client on that interface already exists(7)
how can i have 2 IP address and use one of them to dst-nat for my webserver
i write another time that i don’t have static ip and only provider have it ang give us only with his dhcp server
If you can’t get second IP then you can’t set dst nat
One option is to bridge public interface with interface where web server is connected. THat way server will get one of addresses that provider assigned to you and no DST-NAT is needed.
no dear friend
only i use 3512KB upload bandwidth
i connect 3(1536/512) to mikrotik and also connect webserver to mikrotik(lan ether)
i want to use all upload bandwidth by load balancing
if i use bridge between 2 interface i can’t use all BW upload for my webserver
at first, you should use DNS load-balancing on your three addresses of those three connections - you cannot upload via different uplinks with one src-address, I believe - your ISP will block that
I really wish Mikrotik would implement a relative IP reference to a source or destination field in the firewall/NAT enviroment.
Cisco ASA has an option to just refer to the interface as an IP source or destination which in turn points to the IP adres(ses) given to that particular interface weither this IP is static or dynamic.
Working with scripts on network devices to get basic stuff like this working always gives me the heebie jeebies.
That’s exactly what I mean! Rather than defining a new field (dst-address-type) I would suggest using the dst-address field to also accept “local” as a valid entry next to an IP address.
Or even beter; The dst-address field should accept an interface name as relative designation for an IP address. Perhaps there are situations where one would want to refer to a dynamic IP on another interface.