Ticket #973 (reopened)

Opened 3 years ago

Last modified 2 weeks ago

Firewall blocks dhcp renewal responses

Reported by: phuzi0n Owned by: somebody
Keywords: Cc:

Description (last modified by phuzi0n) (diff)

The default configuration of the firewall blocks DHCP renewal responses which causes it to request a new IP and for current connections to be dropped whether the address changes or not.

Save this command to the firewall script on the Administration->Commands page to fix it:
iptables -I INPUT -p udp --dport 68 -j ACCEPT

If you wish to use DMZ on the router then also add a port forward for udp port 68 to the router's local IP so that it doesn't get sent to the DMZ.

This command is useful for testing, it will signal udhcpc to renew so that you can check whether the remaining lease time updates or not:
kill -USR1 $(head -n 1 /var/run/udhcpc.pid)

If you're experiencing this problem please leave a reply and link to any forum post you made about it.

Change History

comment:1 Changed 3 years ago by alain

I can confirm this.

comment:2 Changed 2 years ago by haridsv

I can confirm this too.

comment:3 Changed 2 years ago by skydiver

I can confirm this also.
I get from my ISP a DHCP lease of 1 hour.
With the additional firewall rule after 30 minutes the lease is renewed.
Without additional firewall rule of the lease runs out after 60 minutes and a new ip is assigned. Simultaneously, a short WAN connection drop occurs.

comment:4 Changed 2 years ago by phuzi0n

  • Description modified (diff)
  • priority changed from major to critical

comment:5 Changed 2 years ago by reids

I can confirm this. My lease from AT&T is ten minutes, and until I applied the iptables statement above, I was getting disconnected and then reconnected, every ten minutes. wland changed it's PID each time.

With the iptables statement, my renewal is every five minutes or so.

Please fix this glaring issue, it's a router and anyone with ISP assigned DHCP (most people I'd bet) will have an issue with this.

comment:6 Changed 2 years ago by diesel2k

I had the same problem on my wrt320n running 14144. This fixed it!

comment:7 Changed 2 years ago by rabeatz

  • severity set to thoughtliu

Have the same issue with my Buffalo WHR-G300N, running DD-WRT v24-sp2 (01/16/10) std - build 13637. Spoke to a server administrator about intermittent connectivity and they confirmed that the times I momentarily lost connection where the same time that my DHCP lease was expiring. Saved the command and hoping this resolves the issue.

comment:8 Changed 2 years ago by mayurt7

Ok, so I am stumped.

I have the RG assigning 172.16.x.x ips,
my DDWrt is in 192.168.x.x
DDWRT is in DMZPlus mode on the RG
DDWRT gets a public IP
DDWRT firewall fix to allow dhcp correctly is applied, saved and router rebooted.

I still have this issue, where i get huge packet loss:

                                                                                              Packets               Pings
 Host                                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. DD-WRT                                                                                   0.0%    67    0.6   1.5   0.5  29.8   4.4
 2. home                                                                                     0.0%    67    1.3   2.7   1.2  52.9   7.8
 3. 99-63-20-3.lightspeed.mssnks.sbcglobal.net                                              75.8%    67    3.8   4.2   3.2  10.2   1.8
 4. 71.150.49.194                                                                           84.8%    67    7.1   4.1   3.2   7.1   1.3
 5. 71.150.32.132                                                                           89.4%    67   11.8   5.4   3.3  11.8   3.1
 6. 71.150.32.126                                                                           84.6%    66    3.6   5.8   3.6  11.6   3.0
 7. 71.150.32.81                                                                            92.3%    66    3.6   4.8   3.5   9.1   2.4
 8. bb4-p4-0.ksc2mo.sbcglobal.net                                                            0.0%    66    3.4  14.4   3.2 182.4  34.5
 9. 151.164.99.169                                                                           0.0%    66   39.7  47.7  36.3 354.1  44.8
10. 72.14.218.53                                                                             0.0%    66   36.6  37.6  36.4  56.0   3.0
11. 209.85.254.122                                                                           0.0%    66   36.9  39.9  36.7  95.0   9.8
12. 209.85.241.22                                                                            0.0%    66   48.9  52.1  47.9 140.9  15.6
13. 209.85.241.27                                                                            0.0%    66   54.5  49.4  47.6  66.1   3.4
    209.85.241.29
14. 209.85.240.49                                                                            0.0%    66   61.2  53.8  47.8  79.8   6.2
    72.14.239.193
    72.14.239.189
    209.85.240.45
15. iw-in-f104.1e100.net                                                                     0.0%    66   47.8  48.3  47.4  63.6   2.4


Any ideas?

Thanks!

comment:9 Changed 2 years ago by amegyeri

I can confirm the error, but in my router this is not fixed with the additional iptables rule.

I have tried many things, including allowing ALL incoming trafic thruogh iptables, but still my router disconnects all connections on DHCP renweal.
With my provider this is 36 hours, but still it is very disturbing as it kills all my openvpn sessions.

Any other workaround or idea how to troublesshot?
(Apart from having a cron restarting openvpn)

The router is Asus RT-N16 , DD-WRT v24-sp2 (11/25/09) big

Thanks!

P.S. This issue is open since a year?

comment:10 Changed 2 years ago by nosferax

I also have the same error. I was able to fix it by using the proposed command, but it started happening again lately and re-running the same command didn't help.

Is there anything I can do to fix this without losing all my router's parameters ?

I am running Firmware: DD-WRT v24-sp2 (10/10/09) std build 13064.

comment:11 Changed 2 years ago by nosferax

  • Cc nosferax@… added

comment:12 Changed 2 years ago by nosferax

  • Cc nosferax@… removed

I upgraded to a newer build (13525) and using the proposed iptables modification the problem is fixed.

comment:13 Changed 2 years ago by orange80

Same exact problem here with AT&T DSL (not U-Verse). I have added this statement to the firewall and tried some other similar examples found scouring the web for help with this. No matter what, every 10 min, all TCP connections are dropped. This seems like a pretty critical issue considering how many of us are stuck with AT&T for internet service :(

comment:14 Changed 22 months ago by surr3al

Confirmed, same issue here. Added the rule and now it seems to be working fine. About 30 minutes now with no issues.

AT&T DSL
DD-WRT v24-sp2 (10/10/09) mini - build 13064 | Linksys WRT54G/GL/GS

comment:15 Changed 22 months ago by phuzi0n

  • Description modified (diff)

comment:16 follow-up: Changed 21 months ago by yutoon

Confirmed this is still a problem, even with latest release, r14929, 08-12-10 running on Asus RT-N13U.

With a single Win XP wireless laptop as only LAN client, when the DHCP lease expires, no simple method works to re-connect. One must hard reboot modem, then router, then PC to re-establish communication.

Adding Phuzi0n's suggestion to INPUT chain immediately enables communication with ISP's DHCP server, but not sure if that totally fixes the problem.

Dropped Internet is a pain -- at least my wife says so -- and it seems relatively easy to eliminate. But are all bugs ever fixed?

Many thanks to the developers for this excellent software.

comment:17 in reply to: ↑ 16 Changed 21 months ago by yutoon

Replying to yutoon:

EDIT:
With more investigation, opening port 68 DOES NOT totally correct the problem. ISP (Comcast) grants initial lease of only 10 min, then 1 hr (sometimes repeated for third lease), then 8 hours. If any of these tick down and expire, the unable-to-renew problem is triggered (requiring hard resets).

As long as a lease is active, it can be released and renewed normally using web-GUI.

Having difficulty isolating the reason for lease sometimes auto-renewing properly and sometimes failing. (Previous router ran with no problems for years.) Number of wired/wireless clients and active connections are eliminated as factors. This is purely between the router and ISP's DHCP server. Will post if cause can be trapped.

comment:18 Changed 17 months ago by eddwrt

Hi, I'm reporting that I've been having this problem with my Telus DSL DHCP setup using a Asus RT-N13u device on a variety of builds 14xxx+.
Trying the IP table's command has not resolved the problem on 14815, I'm trying some other builds.

I would *really* love to use DD-WRT but with this problem, I keep trying, then switching back to stock :(

Thanks!

comment:19 Changed 5 months ago by obcooltorn

Last edited 7 weeks ago by Sash (previous) (diff)

comment:20 follow-up: Changed 8 weeks ago by Sash

  • Resolution set to fixed
  • Status changed from new to closed

i use dhcp on the wan and its working on current builds

comment:21 in reply to: ↑ 20 Changed 7 weeks ago by phuzi0n

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to Sash:

i use dhcp on the wan and its working on current builds

No it doesn't. It only affects people using certain modems in half-bridge configurations (the modem passes the WAN IP via DHCP to the router). What happens is the router starts out with no WAN subnet so it sends a broadcast to ff:ff:ff:ff:ff:ff 255.255.255.255 and accepts a response from anywhere, then it has say 1.2.3.4/24 (any netmask) assigned to the WAN interface, then it sends a broadcast to ff:ff:ff:ff:ff:ff 1.2.3.255 (its WAN subnet broadcast address) but the modem responds from ff:ff:ff:ff:ff:ff 192.168.1.255 (its local subnet broadcast address) and so the router's firewall rejects it for coming from a different subnet, then the router releases the IP and broadcasts to ff:ff:ff:ff:ff:ff 255.255.255.255 and accept a response from anywhere again.

comment:22 Changed 7 weeks ago by phuzi0n

  • Description modified (diff)

comment:23 Changed 2 weeks ago by kingofnerds

When you say that I need to create a port forward to the routers local IP address, is that the address on the LAN side or the WAN side, or the loopback? And would the source for the port forward be 0.0.0.0 or the 192.168.1.254 of my AT&T Residential Gateway?

comment:24 Changed 2 weeks ago by kingofnerds

I guess I needed to forward it to the LAN IP, and include both ports 67 and 68 in the firewall rule using
iptables -I INPUT -p udp --dport 67:68 -j ACCEPT

I now have my DD-WRT router in DMZ+ in my uverse router and DMZ mode enabled to point to my server from the DD-WRT router.

Last edited 2 weeks ago by kingofnerds (previous) (diff)
Note: See TracTickets for help on using tickets.