I need your help.
I have multiple WAN ip addresses set up on a single interface, single subnet. These addresses are nat-ed for services inside private network like 192.168…
Problem is that the router is choosing an originating ip address randomly!
1.1.1.1/28
1.1.1.2/28
1.1.1.3/28
The router, well today, chose first IP address as preferred ip, god knows when this will be second or third. DAC is automatically installed which can’t be removed or edited, it shows first ip address as preferred ip.
it ignores my preferred ip address given in ip routes
0.0.0.0/0 here I’m setting the ip address in the preferred source fiield, say 1.1.1.3, but the preferred ip is the one it installed in DAC
prefered-src property on route is only used for packets originating from router itself (and only some of it). For NATed traffic use action=src-nat with explicit to-addresses setting … you can have multiple src-nat rules for special cases. Simply keep in mind that rules are matched in order from top to bottom, first matching rule evaluates and matching stops (so have the general catch-all rule the last).
The sad fact is that with dynamic WAN settings one can not do much … except with some smart scripting and if things change, it’ll take a short while before script takes care of the rest.
ok, so I should set it in the nat rules, right? what if I don’t know destination? ok, as Ca6ko said I’ll try to explain more detailed way
My router has two WAN interfaces, one of them is set up with just single ip address, and the originating ip address of this interface is just its single ip address, by default. no problem here.
Trouble is on another interface that has multiple ip addresses:
1.1.1.1/28 → without NAT
1.1.1.2/28 → NAT to services inside private network, for example 192.168.10.10
1.1.1.2/28 → NAT to service say 192.168.10.11
1.1.1.3/28 → NAT to service say 192.168.10.21
ok. say 192.168.10.21 is a mail server. Incoming wan ip address for this service chosen to be 1.1.1.3. PTR record is set to 1.1.1.3. When someone sends email using this server, the router sends packets with randomly choosen originated ip address (preferred source), I want it to be 1.1.1.3
All these IP addresses are in one single subnet, splitting them into separate subnets if just bad idea imho.
Before setting up this router, I had windows server with all threse IP addresses on a single interface, I just picked one of these addresses as a preferred source during an add command in powershell.
Remember: every NAT rule (either src or dst nat) has 3 parts:
type of rule … action and chain properties from the above example
values of resulting fields. to-addresses and to-ports
Which of original fields get replaced depends on type of rule … src-nat replaces src-address and/or src-port, dst-nat replaces dst-address and/or dst-port
selection criteria … used to select if packet needs to be processed by a rule. Packet has to match all selection criteria.
In above example that’s src-address and out-interface … if routing engine determines that out interface is not as set in nat rule, then rule will not apply.
Also keep in mind that “return packets”, i.e. packets belonging to connection established from “the other side” (dst-nat’d connections) are not subject to src-nat, instead they’re “inverse dst-nated”. Which should take care of discrepancy where client uses one WAN IP address, router correctly dst-nats it but src-nat would use different WAN IP for return packets (which wouldn’t be fine with client).
I’ve added that rule on top of other nat rules and the machine got ip address I wanted! thanks a lot!!!
carefully reading your last post one thing came to my mind if it’s possible to set it up the way so every WAN ip address will have it own source IP? without exclusively giving the matching rule between wan and lan ip addresses? So if I connect to 1.1.1.2 the source address will be always 1.1.1.2 no matter what?
One thing is DST-NAT … as I wrote DST-NAT makes sure that return packets are properly “un-nated”. So if you use 1.1.1.2 in DST-NAT rule, return packets will use it.
But that doesn’t cover connections, initiated from same machine inside LAN, you have to configure appropriate SRC-NAT rules. Remember, SRC-NAT and DST-NAT rules are independent. If you want to make things seemingly connected, you have to do it manually.
A semi-automatic thing is to create SRC-NAT with action netmap. Its function is a bit of a magic, but normally it’s used in a 1:1 scenario (meaning one needs same number of WAN addresses as there are LAN addresses). Personaly I’ve no experience, but it seems that it’s possible to use it with fewer WAN addresses and it’ll round-robin addresses used in some sort of permanent mapping. You’ll have to experiment.
IMO it’s often not worth trying to get at some persistent load-sharring SRC-NAT, it’s completely fine to get a few hundred users behind single WAN IP (even if organisation owns a /24 of public address space)… unless those users create huge number of long-lasting connections to same set of internet servers which would cause depletion of available src-ports … You can simply use one to host all SRC-NAT and use the rest for DST-NAT. Then you might want to create “related” SRC-NET to use same WAN IP (e.g. if you have DST-NAT towards SMTP server, you may want to have also SRC-NAT using same WAN IP, but only for SMTP traffic), unrelated traffic (e.g. https towards update.microsoft.com) can be handled by generic SRC-NAT rule, internet doesn’t have to know it’s traffic ftom the same LAN server.
I think first option is good for scenario where you want to just bind external ips to internal ones and forget about config existance. In my case several wan ip addresses are bound to a single ip address and I’m not sure what will be next requirement for services inside this network.
load-sharing SRC-NAT, this maybe is good for office environment? As mostly my traffic is from outside to inside. Separating SRC-NAT from DST-NAT by ip addresses is a good idea though!! Never thought about that.