ryan6608
join:2008-11-25
3 edits | 2wire DMZ settings not 'sticking'? Possible solution...
I was having problems keeping my own NAT device in the DMZ of a 2wire device and believe I have tracked down the cause.
The devices I am using are as follows:
2wire 3800HGV: Version 5.29.135.13
IPCOP: Version 1.4.21
However, I believe this may also apply to other linux based firewall / NAT devices.
To add my device to the DMZ of the 2wire device I would go into the 2wire configuration and put the IPCOP device in the DMZ via:
Home Network -- Advanced Settings -- Edit Address Allocation
I would:
1. Uncheck the Firewall Protection check box
2. Set the address assignment to Public (select WAN IP Mapping)
3. Set the WAN IP Mapping to Router WAN IP address (default)
After saving the settings the Device Status for my IPCOP device would change from Connected DHCP to RENEW. I would then log in to the web-gui of my IPCOP device and renew the WAN IP address or restart the device:
1. Go to: SYSTEM -- HOME
2. Click: Disconnect
3. Click: Connect
Restarting the device has the exact same effect. At this point the WAN IP address of my IPCOP device would be renewed and appear to be functioning properly. However, any of the following 3 actions (on the IPCOP device) would cause the WAN IP address to be re-assigned a private (RFC 1918) address:
1. A reboot.
2. Disconnect / Connect the WAN interface (via the web interface).
3. Wait 10 min for the DHCP address to renew (lease time is 600 seconds).
I believe the issue has to do with caching in the dhcp client on the IPCOP device. I'm not sure which device isn't behaving to specification and don't intend to investigate the issue any further. IPCOP uses a DHCP client daemon named dhcpcd which contains the following bit of information for the '-k' switch in the man page:
-k : Sends SIGHUP signal to the dhcpcd process that is currently running. If dhcpcd receives SIGHUP it will send DCHP_RELEASE message to the server and destroy dhcpcd cache. In a case dhcpcd receives SIGTERM which is normally used by shutdown(8) when rebooting the system dhcpcd will not send DHCP_RELEASE and will not destroy cache. When system boots dhcpcd will use cache to request the same IP address from DHCP server which was assigned before the system went down.
Cache and configuration files related to the dhcpcd daemon are located in the following directory for IPCOP:
/etc/dhcpc
If you add the IPCOP device to the DMZ on the 2wire device and disconnect / connect the IPCOP device using the web-gui while watching the files in the above directory you'll notice that, even though the 2wire device assigns a routable IP address for the first DHCP renew request after configuration changes, the cache for the dhcpcd daemon doesn't seem to get updated. I was watching the .info file.
Due to the above, the second DHCP renew request asks to be assigned the cached (private in my case) IP address and the 2wire device complies. If you log into the 2wire configuration at this point it will likely have the address assignment set to Static (at least mine did).
To get the DMZ Plus settings to 'stick' you can do the following:
1. Log into the 2wire device and add your IPCOP (or other linux based router that uses the dhcpcd daemon) to the DMZ.
2. Save the settings. The device status should change to RENEW.
3. Access your IPCOP device via the console and restart the dhcpcd daemon (for the WAN interface) by hand:
3a. dhcpcd -k [interface name]
3b. dhcpcd [interface name]
At this point the cache for the dhcpcd daemon should be updated properly and will stop requesting a stale address from the 2wire device. If the WAN IP of your 2wire device changes you may need to repeat the process.
I believe this issue could be solved by either vendor. |
