Using ip helper-address on a nat inside interface

So I have a few routers that I can no longer afford to put “real” addresses and I would rather use the 100.64.0.0/12 space (this is for NAT444). But for some reason, the router is sending to our DHCP server the nat inside interface address and not the nat translated outside ip address.

interface TenGigabitEthernet0/0/0.95
 ip address 199.1.1.15 255.255.255.128
 no ip redirects
 ip nat outside

interface TenGigabitEthernet0/0/0.98
 ip dhcp relay information trusted
 ip dhcp relay information option-insert 
 ip dhcp relay information check-reply 
 ip address 100.64.4.2 255.255.252.0
 ip helper-address 199.111.111.111
 ip nat inside
 standby version 2
 standby 98 ip 100.64.4.1
 standby 98 priority 105

ip nat pool TOWER_POOL 199.1.1.32 199.1.1.47 prefix-length 25
ip nat inside source list TOWER_NAT pool TOWER_POOL overload
ip access-list standard TOWER_NAT
 permit 100.64.4.0 0.0.3.255

When looking at the tcpdump at the DHCP server, you can see the router is encapsulating the actual gateway-ip and therefore having the packet routed back to that address. The more I think about this particular issue, the more I’m not sure it can be solved through the NAT translator directly on this router without introducing another router (one that has the DHCP client, and another that does the NAT translation). Needless to say, thats not a likely scenerio at this point…

23:33:16.440276 IP (tos 0x0, ttl 254, id 413, offset 0, flags [none], proto UDP (17), length 334)
    c-199-1-1-32.cgnat.company.com.biff > dhcp64.company.com.bootps: [udp sum ok] BOOTP/DHCP, Request from b0:e4:d5:7e:5f:5a (oui Unknown), length 306, hops 1, xid 0xfee44dd1, secs 16115, Flags [none] (0x0000)
          Gateway-IP 100.64.4.2
          Client-Ethernet-Address b0:e4:d5:7e:5f:5a (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Client-ID Option 61, length 7: ether b0:e4:d5:7e:5f:5a
            NOAUTO Option 116, length 1: Y
            MSZ Option 57, length 2: 1500
            Vendor-Class Option 60, length 8: "NestWifi"
            T145 Option 145, length 1: 1
            Parameter-Request Option 55, length 15: 
              Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway
              Domain-Name-Server, Hostname, Domain-Name, MTU
              BR, Lease-Time, Server-ID, RN
              RB, Option 119, Option 252
            Agent-Information Option 82, length 14: 
              Remote-ID SubOption 2, length 12: ^B^J^@^@d@^D^B^@^@^@b
            END Option 255, length 0
23:27:14.184952 IP (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 406)
    dhcp64.company.com.bootps > 100.64.4.2.bootps: [udp sum ok] BOOTP/DHCP, Reply, length 378, hops 1, xid 0x1d5006d9, Flags [none] (0x0000)
          Client-IP 100.64.4.248
          Your-IP 100.64.4.248
          Gateway-IP 100.64.4.2
          Client-Ethernet-Address 52:54:00:2c:cc:f2 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Subnet-Mask Option 1, length 4: 255.255.252.0
            Default-Gateway Option 3, length 4: 100.64.4.1
            Domain-Name-Server Option 6, length 12: dns9.quad9.net,dns.quad9.net
            Hostname Option 12, length 9: "home-v098"
            Domain-Name Option 15, length 16: "company.com"
            Lease-Time Option 51, length 4: 120
            Server-ID Option 54, length 4: dhcp64.company.com
            RN Option 58, length 4: 60
            RB Option 59, length 4: 90
            Client-ID Option 61, length 7: ether 52:54:00:2c:cc:f2
            T119 Option 119, length 28: 208888169,1818848884,1701998181,1946379119,1828717939,1634299000,40070912
            Agent-Information Option 82, length 14: 
              Remote-ID SubOption 2, length 12: ^B^J^@^@d@^D^B^@^@^@b
            END Option 255, length 0

Hello Marcos

It looks like you’ve come to the conclusion that NAT is not a solution for this particular problem that you are facing. I believe that this has to do with the order of operations that NAT employs. If you have separate devices performing these functions you will most likely resolve your issue. Unfortunately, I can’t be more helpful than that, but I’m hoping that you’ll keep us updated on the results of any experiments you may do…

I hope this has been helpful!

Laz