What's new

Solved Strange DHCP source and MAC addresses showing 14 pairs

The most unfortunate thing is that this unsolicited request is accepted by the firewall due to history of many "broken" DHCP servers at ISPs. Even though you're not running Merlin firmware, the code is probably the same in stock ASUS:
C:
/* enable incoming packets from broken dhcp servers, which are sending replies
 * from addresses other than used for query, this could lead to lower level
 * of security, but it does not work otherwise (conntrack does not work) :-(
 */
switch (wan_proto) {
default:
        if (!(nvram_get_int(strcat_r(prefix, "dhcpenable_x", tmp)) || inet_addr_(wan_ip) == INADDR_ANY))
                break;
        /* fall-through */
case WAN_DHCP:
        fprintf(fp, "-A INPUT -p udp --sport 67 --dport 68 -j %s\n", logaccept);
        break;
yes that seems to describe the problem possibility quite well.
 
Yes, is strange since occasionally my routers GW IP (CORRECTION very similar to my GW IP) will also show as doing dhcp at the same time as the other IP transaction shows up. This is a brand new router, is there a problem with ASUS security and their firewall? I do not know how it could have been compromised to be honest except when it first got a public ip from the ISP. But what are the odds? Will flashing back to factory settings help? This has been done a couple times so I would have thought it would have been corrected but still exists. EDITED: I suppose this doesn't help to flash if it will just rehappen through the ISP?
There is nothing wrong with your router, it has not been compromised. This is normal behaviour for Asus routers with certain ISP's. My advice: turn off firewall logging and stop fretting over nothing.
 
The most unfortunate thing is that this unsolicited request is accepted by the firewall due to history of many "broken" DHCP servers at ISPs. Even though you're not running Merlin firmware, the code is probably the same in stock ASUS:
C:
/* enable incoming packets from broken dhcp servers, which are sending replies
 * from addresses other than used for query, this could lead to lower level
 * of security, but it does not work otherwise (conntrack does not work) :-(
 */
switch (wan_proto) {
default:
        if (!(nvram_get_int(strcat_r(prefix, "dhcpenable_x", tmp)) || inet_addr_(wan_ip) == INADDR_ANY))
                break;
        /* fall-through */
case WAN_DHCP:
        fprintf(fp, "-A INPUT -p udp --sport 67 --dport 68 -j %s\n", logaccept);
        break;
Unfortunately there doesn't seem to be a solution if the firewall is going to let it in.
 
Thanks everyone for your help, input and advice! I know you are all busy people so thanks for taking the time to share your expertise! It is greatly appreciated!
 
follow up on this issue regarding 30.46.144.1
  • The DoD Network Information Center (DNIC) manages a large pool of IP addresses, including those used by the Department of Defense.
  • Home routers may occasionally assign IP addresses from this pool to devices connected to the network, especially if the local ISP is utilizing these addresses due to a shortage of available IPv4 addresses.
  • If a home router connects to a network that uses DNIC-managed IP addresses, users may see these addresses logged in their router's firewall.
  • This situation can occur when ISPs borrow unused DoD IP addresses to accommodate their network needs, especially in areas with high demand for internet connectivity.
 
follow up on this issue regarding 30.46.144.1
  • The DoD Network Information Center (DNIC) manages a large pool of IP addresses, including those used by the Department of Defense.
  • Home routers may occasionally assign IP addresses from this pool to devices connected to the network, especially if the local ISP is utilizing these addresses due to a shortage of available IPv4 addresses.
  • If a home router connects to a network that uses DNIC-managed IP addresses, users may see these addresses logged in their router's firewall.
  • This situation can occur when ISPs borrow unused DoD IP addresses to accommodate their network needs, especially in areas with high demand for internet connectivity.
Whilst not disagreeing with this post, it sounds like an answer that was generated by AI?
 
follow up on this issue regarding 30.46.144.1
  • The DoD Network Information Center (DNIC) manages a large pool of IP addresses, including those used by the Department of Defense.
  • Home routers may occasionally assign IP addresses from this pool to devices connected to the network, especially if the local ISP is utilizing these addresses due to a shortage of available IPv4 addresses.
  • If a home router connects to a network that uses DNIC-managed IP addresses, users may see these addresses logged in their router's firewall.
  • This situation can occur when ISPs borrow unused DoD IP addresses to accommodate their network needs, especially in areas with high demand for internet connectivity.
Home routers should not be assigning from this public pool.... What the....
 
update:
I was able to capture the dhcp traffic and it showed the ISP has it's dhcp servers on their private network. I forgot this is the common setup for domains.The DoD IP addressing would then seem to possibly be used as dhcp helpers to point back to the private subnets as it specifically refers to the private subnet in the dhcp ack. There are two of those DoD block IPs involved. One IP refers to a Commscope (formerly Arris Group) MAC address which appears to be either the ISP router (or perhaps the actual owner of the 30.46.x.x IPs). The modem in this loop has two Sercomm MAC addresses which eliminates other MACs on my end.

Also in the dhcp ack, the 30.46.144.1 is specifically listed as: Router and is assumed to be the ISP router GW IP whose broadcast is hitting the ASUS WAN MAC seen in the system log. Lastly, as I previously was unable to capture dhcp traffic inside the lan, the assumption is it is not currently getting through the firewall and not of concern on my local net. The dhcp traffic is abnormally frequent for some reason and does not align with any dhcp lease times shown.

In summary, yes it looks like the suggestions mentioned early in the post that this concern was really just ISP noise and that it could be ignored is probably sufficient advice in this case. However, I would guess most people concerned about their network security would look further to validate that advice. It is of some concern to some of us non-networking trained consumer/users when the setup abnormally uses non-ISP IP addressing which at least theoretically could also allow access to this traffic from outside the ISP block allocation. For the benefit of the ISP, we can graciously assume they at least temporarily leased those IP blocks. Hope this helps anyone else who has similar questions.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Back
Top