Can you try rebooting your gateway device after you connect it to ClearOS? What sort of device is it?

Are there any clues in ./var/log/messages - anything to do with dhclient?

It may be possible that your ISP only assigned the IP to your PC's MAC ADDRESS and not your ClearOS box?

I don't know anything about a poweredbyclear.com fqdn; I'm assuming it's something created during setup that I overlooked and forgot because I have my own fqdn.

Anyway, remote access is out for now, I need to talk to my ISP about that, my public-facing IP address directs to my wireless gateway; such is life.

cat /var/log/messages | grep dhclient produces the following
Dec 14 17:09:32 firewall dhclient[23237]: DHCPACK from 192.168.222.1 (xid=0x4f4f9c5d)
Dec 14 17:09:34 firewall dhclient[23237]: bound to 192.168.222.108 -- renewal in 208 seconds.
Dec 14 17:29:43 firewall dhclient[17248]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 (xid=0x5bb7a32b)
Dec 14 17:29:43 firewall dhclient[17248]: DHCPOFFER from 192.168.222.1
Dec 14 17:29:43 firewall dhclient[17248]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x5bb7a32b)
Dec 14 17:29:43 firewall dhclient[17248]: DHCPACK from 192.168.222.1 (xid=0x5bb7a32b)
Dec 14 17:29:45 firewall NET[17353]: /sbin/dhclient-script : updated /etc/resolv-peerdns.conf
Dec 14 17:29:45 firewall dhclient[17248]: bound to 192.168.222.108 -- renewal in 228 seconds.
Dec 14 17:31:36 firewall dhclient[21024]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0xa291ec6)
Dec 14 17:31:43 firewall dhclient[21024]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0xa291ec6)
Dec 14 17:31:43 firewall dhclient[21024]: DHCPACK from 192.168.222.1 (xid=0xa291ec6)
Dec 14 17:31:45 firewall NET[21231]: /sbin/dhclient-script : updated /etc/resolv-peerdns.conf
Dec 14 17:31:45 firewall dhclient[21024]: bound to 192.168.222.108 -- renewal in 230 seconds.
Dec 14 17:35:35 firewall dhclient[21235]: DHCPREQUEST on eth1 to 192.168.222.1 port 67 (xid=0xa291ec6)
Dec 14 17:35:38 firewall dhclient[21235]: DHCPREQUEST on eth1 to 192.168.222.1 port 67 (xid=0xa291ec6)


I only grabbed the most interesting parts; nothing to see there; same entries repeated. Setting to DHCP now to see what it shows new:

cat /var/log/messages | grep dhclient produces the following
Dec 14 17:39:27 firewall dhclient[27526]: bound to 192.168.222.108 -- renewal in 290 seconds.
Dec 15 19:12:10 firewall dhclient[24305]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 (xid=0x796b54b0)
Dec 15 19:12:15 firewall dhclient[24305]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6 (xid=0x796b54b0)
Dec 15 19:12:15 firewall dhclient[24305]: DHCPOFFER from 192.168.222.1
Dec 15 19:12:15 firewall dhclient[24305]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x796b54b0)
Dec 15 19:12:15 firewall dhclient[24305]: DHCPACK from 192.168.222.1 (xid=0x796b54b0)
Dec 15 19:12:17 firewall NET[24505]: /sbin/dhclient-script : updated /etc/resolv-peerdns.conf
Dec 15 19:12:17 firewall dhclient[24305]: bound to 192.168.222.108 -- renewal in 234 seconds.
Dec 15 19:12:25 firewall dhclient[24993]: DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x22a2404)
Dec 15 19:12:25 firewall dhclient[24993]: DHCPACK from 192.168.222.1 (xid=0x22a2404)
Dec 15 19:12:27 firewall NET[25087]: /sbin/dhclient-script : updated /etc/resolv-peerdns.conf
Dec 15 19:12:27 firewall dhclient[24993]: bound to 192.168.222.108 -- renewal in 277 seconds.

[root@firewall ~]# cat /etc/resolv-peerdns.conf
; generated by /sbin/dhclient-script
nameserver 8.8.8.8
nameserver 8.8.4.4

Some more:
[root@firewall ~]# ping 8.8.8.8
connect: Network is unreachable
[root@firewall ~]# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
connect: Network is unreachable
[root@firewall ~]# ping 192.168.222.108
PING 192.168.222.108 (192.168.222.108) 56(84) bytes of data.
64 bytes from 192.168.222.108: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 192.168.222.108: icmp_seq=2 ttl=64 time=0.019 ms
^C
--- 192.168.222.108 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1159ms
rtt min/avg/max/mdev = 0.019/0.030/0.041/0.011 ms
[root@firewall ~]# ping 192.168.222.1
PING 192.168.222.1 (192.168.222.1) 56(84) bytes of data.
64 bytes from 192.168.222.1: icmp_seq=1 ttl=64 time=0.255 ms
64 bytes from 192.168.222.1: icmp_seq=2 ttl=64 time=0.197 ms
^C
--- 192.168.222.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1238ms
rtt min/avg/max/mdev = 0.197/0.226/0.255/0.029 ms


As soon as I assign the IP address as static (as before) everything works again.

With static-set IP address:
[root@firewall ~]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:0A:CD:23:89:AF
inet addr:192.168.222.108 Bcast:192.168.222.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6245294 errors:0 dropped:0 overruns:0 frame:0
TX packets:3777710 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8309148145 (7.7 GiB) TX bytes:465808749 (444.2 MiB)


With DHCP-set IP address:
[root@firewall ~]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:0A:CD:23:89:AF
inet addr:192.168.222.108 Bcast:192.168.222.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6245413 errors:0 dropped:0 overruns:0 frame:0
TX packets:3777789 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8309170365 (7.7 GiB) TX bytes:465818901 (444.2 MiB)

Different IP addresses for both machines. My desktop received a different address.

I've rebooted everything. I'm not sure what type of device it is specifically, but it's microwave wireless or similar. My previous ISP was microwave, and this new one is similar but with newer technology.

I haven't checked /var/log/messages, and I can't now because I don't have my new public IP memorized/written down yet to access while I'm at work.

The ISP should be calling me back today, I'll see what they have to say as well. It seems like it's going to be my ClearOS box, though. I'm running 6.6 Community, will probably update to 7.0 this weekend.

Try remembering your free poweredbyclear.com fqdn but change it to something memorable first.

What is odd is the short lease time and why it is refreshing so quickly. You could try adding "supersede dhcp-renewal-time 3600;" to /etc/dhcp/dhclient.conf then do a "service dnsmasq restart". If that succeeds in adding stability the problem is an ISP issue, which I suspect it is anyway. Do not leave the hack in /etc/dhcp/dhclient.conf long term as it could cause problems. You can also try logging packets with tcpdump to see if the messages contain much more information.

Your with and without DHCP ifconfig dumps look the same. Is that correct or have I missed something?

On a completely different tack, what is the output of:

lspci -k | grep Eth -A 3

uname -r

[root@firewall dnsmasq.d]# lspci -k | grep Eth -A 3

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)

        Subsystem: Dell OptiPlex 755

        Kernel driver in use: e1000e

        Kernel modules: e1000e

--

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)

        Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI Gigabit Ethernet NIC

        Kernel driver in use: r8169

        Kernel modules: r8169

[root@firewall dnsmasq.d]# uname -r

2.6.32-573.1.1.v6.x86_64

I tried your supersede hack, but it didn't appear to do anything.

Your drivers look Ok, or at least I have not heard of any problems with them. There is one more thing you can try and that is to spoof the MAC address of the computer which works when directly connected. To find the MAC address from a Windoze command prompt do an "ipconfig /all" or from a linux terminal "ifconfig". Input this address in the /etc/sysconfig/network-scripts/ifcfg-ethX file for your WAN NIC in the form:

MACADDR=aa:bb:cc:dd:ee:ff

(I am not sure which case to use. udev needs lower case but ifconfig reports in upper case) then restart the interface with:

ifdown ethX && ifup ethX

If this works it is really an ISP issue where they have locked your modem to your PC, but you can make this change permanent by setting the immutable bit on the file:

chattr +i /etc/sysconfig/network-scripts/ifcfg-ethX

This will stop anything making changes to the file including the webconfig. To undo it use -i instead of +i

I have had this same issue ever since I started using ClearOS6, and now 7. I have Comcast (cable internet) and use a Motorola SB6141, although I had the same exact issues with a Ubee modem (also with the same Comcast service). I have never been able to figure out what is causing the issue. If I reboot the clear server I will lose the internet, if I modify the adapter same thing, same goes for if the modem is reset - poof. I can connect any standard router (linsys, netgear) to the modem and it will get an IP after a modem power cycle no problem. This does not work for ClearOS.

I was able to connect to the modem with my laptop and get an IP, then clone the laptops MAC on my clear server and manually set the IP instead of DHCP and this will grab the IP and give me the web. But that won't work cause I have DHCP service, and I don't like it.

The other way I have been able to (repeatedly) get my connection back after a reset is to move the modem input cable to a different NIC. I happen to have more NICs than anyone should so I happened to figure it out. If I power cycle the modem and leave the cable plugged into the server the modem comes up but no internet yet. Then I will move the modem cat5 from one NIC to another. This new NIC will reach out and grab an IP for some unknown reason. It does give me a new IP (no big deal really) but I also get my internet back.

So every time something gets reset (like a power outage) I have to swap cables around and then edit my domain DNS entries (yay!). I had though of putting a little router as a sort of bridge in between clearos and the modem but I don't like that idea at all. I would love to find the solution for this problem, it drives me nuts.

Does this indicate a hardware error? This is where I was going next. As both your NIC's are gigabyte NIC's can you swap them round? The easiest (cheating) way is to go into /etc/udev/rules.d/70-persistent-net.rules and change the ethX assignments then reboot and swap the cables round. Otherwise you bay have to make the change from the console directly rather than from a PC.

Swapped my NIC's...everything works. Weird. Now I just have to make them let me access my systems remotely instead of just their gateway...

So now my eht0 is my External, set up with DHCP:

[root@firewall ~]# ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:1E:4F:A1:428

          inet addr:192.168.222.218  Bcast:192.168.222.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:39067952 errors:0 dropped:0 overruns:0 frame:0

          TX packets:51166543 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:8087300957 (7.5 GiB)  TX bytes:60878001237 (56.6 GiB)

          Interrupt:21 Memory:fe9e0000-fea00000

Eth1 is now configured as my LAN interface with my assigned static address:

[root@firewall ~]# ifconfig eth1

eth1      Link encap:Ethernet  HWaddr 00:0A:CD:23:89:AF

          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:45614664 errors:0 dropped:0 overruns:0 frame:0

          TX packets:29556616 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:60056657806 (55.9 GiB)  TX bytes:5679028488 (5.2 GiB)

The TX/RX numbers are not from the switch, they're from before, few days, so don't mind those.

I'm still trying to get hold of my ISP, the haven't called me back yet and I'm starting to get really upset about that, but if I had to guess at this point, I would say the problem is with my ClearOS box. It just seems that it isn't routing property with eth1 set up as External/DHCP.

Side not, speed took a drastic hit. That's not acceptable. Switch it back to the way it was, now I can't get online with my ClearOS box at all...my PC still works fine if directly connected. And my ISP still doesn't answer calls...

New message when restarting network with eth1 External/DHCP:

Bringing up interface eth1:

Determining IP information for eth1.../etc/sysconfig/network-scripts/ifup-eth: line 297:  4091 Terminated              /sbin/dhclient ${DHCLIENTARGS} ${DEVICE}

 failed.

                                                           [FAILED]

Relevant /var/log/messages

Dec 21 17:55:30 firewall kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready

Dec 21 17:55:32 firewall kernel: device eth1 entered promiscuous mode

Dec 21 17:55:34 firewall /etc/sysconfig/network-scripts/ifup-eth: Error adding address 192.168.222.218 for eth1.

Dec 21 17:55:34 firewall kernel: r8169 0000:03:00.0: eth1: link up

Dec 21 17:55:34 firewall kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

Dec 21 17:56:26 firewall kernel: r8169 0000:03:00.0: eth1: link down

Dec 21 18:00:04 firewall kernel: device eth1 left promiscuous mode

Dec 21 18:00:07 firewall kernel: r8169 0000:03:00.0: eth1: link down

It's taken me two hours now, and I've managed to get back online. Probably by sheer luck, but I am back to Eth1/External/DHCP. I've spoofed my PC's MAC address, no change. I gave it a random MAC address, no change. Perhaps the ONE thing I finally did was disconnect the gateway from POE, set MAC address back to default, reboot server, then plug power back into the gateway after server was up; DHCP still didn't work, changed to static, and voila.

The internet, I think, hates me.

Finally got hold of my ISP, all they had to say was that it should be configured to DHCP, and I should reset my firewall (they never did really understand that I have a Linux box...) and the wireless gateway, as if I hadn't done that before.

To get remote access, they require I have a static IP address because that costs an extra $5/mo...bastards.

Anyway, everything's working with a proper static IP address...still no idea why it wasn't working, and the only way I was going to get an answer from them was to continue not having a reliable connection which I wasn't going to do.

Thanks for your help guys, too bad we couldn't come to a better solution.