Forwarding From Old Subset To New Subnet After Switching Subnet?

[HarryMuscle]

I'm planning to switch my subnet from the super common 192.168.1.x to something more unique like 192.168.22.x for example (to avoid VPN related IP address conflicts). However I have some printers that various clients access via hard coded IP addresses. Until I get around to changing those on all the clients, is it possible to tell the router to forward any attempts to connect to 192.168.1.123 (the printer's original IP in the old subnet) to 192.168.22.123 (the printer's new IP) when coming from clients on the new subnet? Here's what I'm after illustrated:

Client (192.168.22.50) -> Attempt connection to 192.168.1.123 (old hard code printer IP) -> Router (192.168.22.1) -> Forward to 192.168.22.123 (printer's actual IP in new subnet) -> Printer (192.168.22.123)

I'm hoping it's just a matter of adding some iptables rules.

Thanks,
Harry

 

[drinkingbird]

I'm planning to switch my subnet from the super common 192.168.1.x to something more unique like 192.168.22.x for example (to avoid VPN related IP address conflicts). However I have some printers that various clients access via hard coded IP addresses. Until I get around to changing those on all the clients, is it possible to tell the router to forward any attempts to connect to 192.168.1.123 (the printer's original IP in the old subnet) to 192.168.22.123 (the printer's new IP) when coming from clients on the new subnet? Here's what I'm after illustrated:

Client (192.168.22.50) -> Attempt connection to 192.168.1.123 (old hard code printer IP) -> Router (192.168.22.1) -> Forward to 192.168.22.123 (printer's actual IP in new subnet) -> Printer (192.168.22.123)

I'm hoping it's just a matter of adding some iptables rules.

Thanks,
Harry

It won't work because when you go update your clients, the NAT rule you put in place will break the connectivity to the new IP, the return traffic gets NAT'd back to the old 192.168.1.x still. There is probably some complex policy based NAT or routing you could try and do, but why not just go around and update the clients to use a hostname instead of IP, then when that is done, switch your subnet. It is the cleaner and easier solution and sets you up to avoid this issue in the future.

Or just have your VPN use something other than 192.168.1.x.

If your printer has a wireless and wired network interface you could potentially get both running at the same time (some allow this) one in the new subnet, one in the old, and set up routing to make it work.

 

[ColinTaylor]

Try this, it should do what you want. If it works put it in a nat-start script. But as @drinkingbird said, the "proper" solution is for the clients to use host names rather than hard-coded IP addresses.

iptables -t nat -I PREROUTING -d 192.168.1.123 -j DNAT --to-destination 192.168.22.123

 

[drinkingbird]

Try this, it should do what you want. If it works put it in a nat-start script. But as @drinkingbird said, the "proper" solution is for the clients to use host names rather than hard-coded IP addresses.

iptables -t nat -I PREROUTING -d 192.168.1.123 -j DNAT --to-destination 192.168.22.123

I'm not sure how iptables handles static NATs but usually a 1:1 nat will NAT return traffic (stateless) so once a client starts pointing to the new IP it would break the connection and not work, as it will still NAT one direction. Policy based NAT can overcome that but it gets complex. Maybe iptables is smart enough to only do the reverse NAT for stuff that hit the forward NAT though (inherently doing policy NAT), never tried it.

Obviously need to get the two subnets working in the first place too, not sure if adding a secondary subnet on the same interface will be enough to allow it to hit IPtables and for NAT to happen, may need another bridge interface.

EDIT, ok I think your statement is doing an overload NAT and not a static. That should work in theory, as long as the printer doesn't need to initiate to the client (many do, but may be able to live without those functions during the migration phase).

 

[ColinTaylor]

@drinkingbird I think you're overthinking this, or I'm missing the OP's point. The traffic that is DNAT'ed finds it's way back because of conntrack. Once the client is reconfigured for the new subnet the iptables rule is redundant as it isn't being routed.

 

[drinkingbird]

@drinkingbird I think you're overthinking this, or I'm missing the OP's point. The traffic that is DNAT'ed finds it's way back because of conntrack.

Yes I was assuming an SNAT due to most printers having front panel scan to PC etc functions. If DNAT is sufficient (printing only, no warnings about out of paper or ink levels, etc), then that will work. But you still need to get the second subnet and routing working.

I still think OP is actually overthinking it and should first just get everyone switched to a hostname then hot cut the subnet over and be good to go.

 

[ColinTaylor]

I still think OP is actually overthinking it and should first just get everyone switched to a hostname then hot cut the subnet over and be good to go.

Yes this is the way. Having gone through the pain of having to do this with scores of printers in a corporate network, it's not fun. Clients should use something like "payroll-printer" instead of an IP address and the printers should get their IP address from DHCP (unless there's a very good reason not to).