eth0:0 is a label, not a device: fix the SNAT match

A NAT rule that was supposed to give one VPN client pool its own public address sits at zero packets, while the same pool keeps leaving under the wrong source. The rule is usually not wrong about the address; it is wrong about the interface. -o eth0:0 refers to a device that does not exist, because eth0:0 is a label attached to an address on eth0. Watching the counters is the fastest way to confirm it, and the fix is smaller than the investigation suggests.

Check what the kernel calls the device

Read the two views separately before changing anything:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

The link listing shows interfaces. The address listing may show a second IPv4 address carrying the label eth0:0, and the device for that address is still eth0. The iproute2 address manual treats the label as a name for the address, not as a second link, which is the distinction the whole problem turns on.

History explains the confusion. The old ifconfig eth0:0 syntax really did look like a new interface, and scripts from that era still refer to one. On a current system, the alias is a label on an address, and nothing in the routing or netfilter path treats it as a separate egress point.

Check what the rule actually matched

Read the counters with the rule list rather than from memory:

iptables -t nat -L POSTROUTING -v -n --line-numbers

A rule whose packet count stays at zero while matching traffic flows is not being evaluated, and an output-interface condition naming eth0:0 is a common cause. The output device selected by the route is eth0, so a condition looking for a different name never becomes true, no matter which source address the kernel picked.

Change the condition to the real device and leave the label out of it. If you need to distinguish two client pools that share that device, distinguish them by source prefix, not by an interface name that cannot exist. Two rules with non-overlapping -s matches are readable and testable; one rule with a fictional device is neither. Give each rule a comment that names the pool, because six months from now the prefix alone will not tell anyone why it is there.

Check the route that chose the device

Postrouting NAT runs after the route has already selected an output interface, so the interface in the rule must be the one the route picked. Ask the kernel directly with ip route get for a representative client address and read both the device and the source it reports.

If the answer names eth0, the interface part of the rule is settled. If it names a tunnel device, the packet never reaches the rule you are editing, and the search moves to the routing table and its priorities. A rule that never matches because the packet left elsewhere looks identical in the counter output to a rule with a misspelled device. Confirm which of the two you have before you edit anything, because the second needs a routing change rather than a text change.

Choose the translated source on purpose

Once the device is right, the source address is a separate decision. This is an illustrative IPv4 pool and an example address only:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Writing an address into --to-source does not make anyone route it back to you. The upstream provider or the address owner has to deliver replies for that address to this host, and the address has to be one you are authorised to use. If it is not, the rule will match and translate and the replies will still go somewhere else.

Changing the source address is not the same as changing the uplink. When the real requirement is a different physical path, the routing policy has to select that path first; SNAT then rewrites the source on whatever device the policy chose. Adding more labels to eth0 supplies neither the route nor the authorisation.

Verify with a connection you just opened

Open a new client connection rather than reusing an existing one. Connection tracking keeps the translation it recorded when the flow started, so an old session can keep using the previous source address and make a correct new rule look broken. Watch the counter increase, then observe the translated source on the wire or at the far end.

For several pools sharing one interface, give each an explicit source match and its own translation address, keep them in the firewall's managed configuration, and note the order in which they are evaluated. Then record what you verified: the device from ip route get, the counter that moved, and the source the remote side saw. That record answers the next report without repeating the alias confusion.