Never tried this one but you can in general nat traffic originated by the router itself. It just gets a little tricky because router generated messages do not com in a NAT IN interface.
Lets assume we go thought the trouble to get the message to nat. The reason I suspect it won't work is because the way the helper is using fields inside the dhcp request itself to indicate which interface it came from.
So lets assume you have a interface 192.168.1.1 that send a message to a helper and places 192.168.1.1 in the packet as the source interface. Now the source in the ip header of the packet gets natted to 10.10.10.10 but the one in the packet is left untouched and gets sent to the helper. The helper gets the packet looks inside and uses the 192.168.1.1 to generate a ip and places it back in the packets. This is good thing because if it used 10.10.10.10 it would have issues. Now he will attempt to send the packet back to the gateway using 192.168.1.1 which of course doesn't work because it needs to return to 10.10.10.10.
It been a while since I read the helper RFC but I am pretty sure it uses the internal address and not the address on the packets. This is not to say that someone might have a option on a DHCP server to get around this issue.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...