Gentoo box can't cURL or ping after restarting net.eth1

Question

the following is completely baffling me. We currently have a gentoo box which acts as our LAMP, DNS, DHCP server. This is assigned a static IP on the network. This server is connected directly to the internet via a BT BusinessHub Router. The server is also connected to a patch panel/switch port which connects the remaining office (around 10 PC's) to the server.

Everything has been plain sailing until the other day when the server was restarted. For some reason now only portions of network accessibility is available depending on which ethernet device was last restarted. Restarting net.eth0 allows the office server to cURL, ping, etc but stops all networked PC's from accessing the internet. Then restarting net.eth1 restores all internet to the network but stops the server from curling, pinging, etc again.

However, even when the server can't ping, curl, etc, I can still remote SSH and remote MySQL connect from the server command line to other external servers that we own.

Here's my route map (router is 192.168.1.254):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 eth1

Here's my /etc/conf.d/net:

iface_eth0="192.168.1.99 broadcast 192.168.1.255 netmask 255.255.255.0"
iface_eth1="dhcp"

None of the above have ever been changed however. Things have just ceased to operate correctly, which makes me think it's a freshly added Iptables rule. Here's the Iptables Filter table:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  ##.##.##.##          anywhere            tcp dpt:ssh
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:2199
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3199
ACCEPT     tcp  --  ##.###.###.##        anywhere            tcp dpt:http
ACCEPT     tcp  --  ###.###.##.##        anywhere            tcp dpt:2199
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.##.##         anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:3128
ACCEPT     udp  --  ##.###.###.###       anywhere            udp dpt:3128
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:https
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             ##.###.###.##
DROP       all  --  anywhere             ##.###.###.##
ACCEPT     all  --  anywhere             anywhere            state NEW,ESTABLISHED
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere            udp spt:2199
ACCEPT     udp  --  anywhere             anywhere            udp spt:4817
ACCEPT     udp  --  anywhere             anywhere            udp spt:4819
ACCEPT     udp  --  anywhere             anywhere            udp spt:3199

Help gratefully appreciated.

Can you ping 192.168.1.254? What about 4.2.2.1? And www.google.com? If you are behind another NAT firewall you might want to disable your servers firewall for a second and test, an easy way to rule out your firewall config. — Antonius Bloch, Feb 02 '11 at 14:35
If you disable iptables does the problem go away? That's an easy way to determine if the problem is indeed in your iptables ruleset. — larsks, Feb 02 '11 at 14:39
By the way, you posted some public IPs. It's a good idea to obscure those in public forum. It's like saying "Hey hackers, I'm having problems with my firewall config and here is my address!" — Antonius Bloch, Feb 02 '11 at 14:43
Thanks for the tip, i've hashed out all external IP addresses. Just tried a few of your suggestions. @Antonius I can ping 192.168.1.254 and www.google.com from the server itself when .eth0 has been restart (but not after eth1 has then been restarted). @larsks Disabled iptables and the problem still existed. Static IP is being set. — Curlybraces, Feb 02 '11 at 15:07
@Antonius Bloch do you mean /etc/init.d/net.eth0 scripts, etc? If so, they are pretty large. Wouldn't want to spam the post out without due cause. — Curlybraces, Feb 03 '11 at 14:37

score 1 · Answer 1 · answered Jun 06 '11 at 06:16

Do you realize that you have eth0 and eth1 effectively configured for the same subnet?

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

iface_eth0="192.168.1.99 broadcast 192.168.1.255 netmask 255.255.255.0"
iface_eth1="dhcp"

Change the subnet on your router to 192.168.0.0/24, or some other subnet besides 192.168.1.0/24, restart eth1, and that should fix it. Unless the two interfaces are really on the same network -- and they aren't -- they shouldn't be configured for the same subnet.

Also, does all traffic pass through your server to get to the router?

If so, I recommend just turning on bridging on your router to give your server a public IP address. See: http://business.forums.bt.com/t5/Broadband-and-internet/How-to-set-up-bridge-mode-on-the-BT-business-hub/td-p/4902 -- this will avoid the problem entirely, although as I'm not familiar with your router, you may want to avoid this; they call it bridging, looks like it might be a passthrough, where it still does the authentication (does BT do PPPoE/PPPoA auth?), but passes the DHCP info through.

Having two NATing subnets setup is a waste if you don't use/need.

Having two routes to the same destination network on different interfaces will certainly cause networking issues. In the unlikely event that this is not in error, you can use the route metric to break the tie. — Citizen Kepler, Sep 26 '18 at 18:44

score 0 · Answer 2 · answered Feb 02 '11 at 15:16

0

By the sounds of it looks like your interfaces are configured to not allow forwarding by default, so when the interface is restarted it stops the forwarding showing the kind of problem you're having.

Try to add this to your /etc/sysctl.conf

Add/Uncomment the following lines:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

If you have a dynamic internet address you probably want to enable this:

net.ipv4.ip_dynaddr = 1

That should solve your issue

answered Feb 02 '11 at 15:16

lynxman

9,397
3
25
28

Added the top 2 lines to my sysctl.conf. Unfortunately no change. Still either server has net or everyone on the network has net. Thanks for the help though. – Curlybraces Feb 02 '11 at 15:33

Gentoo box can't cURL or ping after restarting net.eth1

2 Answers2