Trouble recreating routing for rebuilt firewall system
by rnturn from LinuxQuestions.org on (#5BK73)
Ouch! A couple of hardware failures clobbered a firewall system on our home LAN---we lost one of the ethernet interfaces as well as the HDD. All the hardware has been put together and Slackware 14.2 installed (the system was formerly running 14.1) but, sadly, my notes about how the routing was configured were packed away after our last move and I can't access them. (Visualize the end of Raiders of the Lost Ark and you'll have a good idea of what it'll take to find them.) Luckily, I have the main iptables setup script available.
The failed network interface lost was an r8169-based gigabit ethernet card (Trendnet) which I replaced with another r8169-based card from D-Link---no problems there. Everything on the "clean" side of the firewall is working. Since the replacement, however, I cannot seem to get the other network interface to talk to anything except via pinging. Oddly, before I got the replacement gigabit card installed, I had been using that other interface to access the internet in a non-firewall configuration to make sure we didn't have an ISP problem (we didn't) and I am able to ping the ISP gateway with "ping -I eth1 <isp-gw-addr>". Of course that's a much simpler configuration.
The current addressing and routing is below (both old-style and new command output):
Code:root@fwallsys:~# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.13.1 netmask 255.255.255.0 broadcast 192.168.13.255
inet6 fe80::f2b4:d2ff:fe0c:9f55 prefixlen 64 scopeid 0x20<link>
ether f0:b4:d2:0c:9f:55 txqueuelen 1000 (Ethernet)
RX packets 98 bytes 6976 (6.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 332 bytes 15861 (15.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet xxx.yyy.zzz.125 netmask 255.255.255.252 broadcast xxx.yyy.zzz.127
inet6 fe80::206:2bff:fe00:24d3 prefixlen 64 scopeid 0x20<link>
inet6 2603:300a:1607:4a00:206:2bff:fe00:24d3 prefixlen 64 scopeid 0x0<global>
ether 00:06:2b:00:24:d3 txqueuelen 1000 (Ethernet)
RX packets 1280 bytes 126035 (123.0 KiB)
RX errors 1 dropped 0 overruns 0 frame 0
TX packets 51 bytes 2554 (2.4 KiB)
TX errors 5 dropped 0 overruns 0 carrier 5 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 91 bytes 7401 (7.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 91 bytes 7401 (7.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@fwallsys:~# ip addr lis
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
inet xxx.yyy.zzz.125/30 brd xxx.yyy.zzz.127 scope global eth1
valid_lft forever preferred_lft forever
inet6 2603:300a:1607:4a00:206:2bff:fe00:24d3/64 scope global mngtmpaddr dynamic
valid_lft 337895sec preferred_lft 337895sec
inet6 fe80::206:2bff:fe00:24d3/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ff
inet 192.168.13.1/24 brd 192.168.13.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f2b4:d2ff:fe0c:9f55/64 scope link
valid_lft forever preferred_lft forever
root@fwallsys:~# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.13.1 0.0.0.0 UG 0 0 0 eth0
xxx.yyy.zzz.124 0.0.0.0 255.255.255.252 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@fwallsys:~# ip route
default via 192.168.13.1 dev eth0 scope link metric 1
xxx.yyy.zzz.124/30 dev eth1 proto kernel scope link src xxx.yyy.zzz.125
127.0.0.0/8 dev lo scope link
192.168.13.0/24 dev eth0 proto kernel scope link src 192.168.13.1Something looks wrong with the eth1 settings but I can't put my finger on it. The default route associated with eth0 was, I'm certain, set by the setting in "/etc/rc.d/rc.inet1.conf".
I'm able to ping an internal workstation from the firewall, and the firewall from the workstation. I am able to ping the eth1 interface from the wifi connection on the Comcast router. Performing name resolution for internal hosts on the firewall works via the internal DNS. The internal DNS fails when trying to forward unknown hostnames to the my domain provider's DNS servers. When specifying Comcast's DNS servers first in /etc/resolv.conf on the firewall name resolution fails. (Well, I killed it after 4-5 sec.)
Thinking that this could be a lack of a route to the ISP's gateway, I tried adding that and got:
Code:root@fwallsys~# ip route add xxx.yyy.zzz.124/30 via xxx.yyy.zzz.126 gw dev eth1
Error: either "to" is a duplicate, or "gw" is a garbage
root@fwallsys~# ip route add xxx.yyy.zzz.124/30 via xxx.yyy.zzz.126 dev eth1
RTNETLINK answers: File existsNone of those answers are very informative though I suspect that the second one might have been complaining that it was trying to duplicate the existing for xxx.yyy.zzz.124. (Which, I assume, was created using the information for eth1 in "/etc/rc.d/rc.inet1.conf".) I've tried different things (preceding the network with -net, inet, and so forth) but "ip route" cryptically complained about all of them. (How, exactly, is this better than "route" again? :^/ )
Questions:
Do I need to set up the gateway for the eth1 interface? And how is this done using "ip route"? (I think this will solve the biggest problem I'm seeing.)
Now, about that "state UNKNOWN"...
The other thing that I really haven't been able to figure out is that the old ethernet card ("eth1" that didn't fail) shows up differently:
Code:root@fwallsys:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ff
root@fwallsys:~# ip link set eth1 down
root@fwallsys:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ff
root@fwallsys:~# ip link set eth1 up
root@fwallsys:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ffI have to admit that I cannot recall whether something like this "state UNKNOWN" message was seen when the firewall was running under Slackware 14.1. It also doesn't seem to have a major effect on the interface since I'm able to ping to the ISP gateway. (Plus it was able to update an initial 14.2 install to -current before I decided to trash it, re-install 14.2, and stick with that.)
More questions:
What would cause "eth1" to have this "UNKNOWN" state?
What does that even mean?
What could be preventing it from being in an "UP" state as "eth0" is?
Does it even matter? Is it just a bogus bit of information?
I've seen RedHat and Arch bug reports about this during searches but most of these are pretty old (2012 and 2013!).
Final question:
Is there more information I should post that would help?
A thousand TIAs...
The failed network interface lost was an r8169-based gigabit ethernet card (Trendnet) which I replaced with another r8169-based card from D-Link---no problems there. Everything on the "clean" side of the firewall is working. Since the replacement, however, I cannot seem to get the other network interface to talk to anything except via pinging. Oddly, before I got the replacement gigabit card installed, I had been using that other interface to access the internet in a non-firewall configuration to make sure we didn't have an ISP problem (we didn't) and I am able to ping the ISP gateway with "ping -I eth1 <isp-gw-addr>". Of course that's a much simpler configuration.
The current addressing and routing is below (both old-style and new command output):
Code:root@fwallsys:~# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.13.1 netmask 255.255.255.0 broadcast 192.168.13.255
inet6 fe80::f2b4:d2ff:fe0c:9f55 prefixlen 64 scopeid 0x20<link>
ether f0:b4:d2:0c:9f:55 txqueuelen 1000 (Ethernet)
RX packets 98 bytes 6976 (6.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 332 bytes 15861 (15.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet xxx.yyy.zzz.125 netmask 255.255.255.252 broadcast xxx.yyy.zzz.127
inet6 fe80::206:2bff:fe00:24d3 prefixlen 64 scopeid 0x20<link>
inet6 2603:300a:1607:4a00:206:2bff:fe00:24d3 prefixlen 64 scopeid 0x0<global>
ether 00:06:2b:00:24:d3 txqueuelen 1000 (Ethernet)
RX packets 1280 bytes 126035 (123.0 KiB)
RX errors 1 dropped 0 overruns 0 frame 0
TX packets 51 bytes 2554 (2.4 KiB)
TX errors 5 dropped 0 overruns 0 carrier 5 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 91 bytes 7401 (7.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 91 bytes 7401 (7.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@fwallsys:~# ip addr lis
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
inet xxx.yyy.zzz.125/30 brd xxx.yyy.zzz.127 scope global eth1
valid_lft forever preferred_lft forever
inet6 2603:300a:1607:4a00:206:2bff:fe00:24d3/64 scope global mngtmpaddr dynamic
valid_lft 337895sec preferred_lft 337895sec
inet6 fe80::206:2bff:fe00:24d3/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ff
inet 192.168.13.1/24 brd 192.168.13.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f2b4:d2ff:fe0c:9f55/64 scope link
valid_lft forever preferred_lft forever
root@fwallsys:~# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.13.1 0.0.0.0 UG 0 0 0 eth0
xxx.yyy.zzz.124 0.0.0.0 255.255.255.252 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
root@fwallsys:~# ip route
default via 192.168.13.1 dev eth0 scope link metric 1
xxx.yyy.zzz.124/30 dev eth1 proto kernel scope link src xxx.yyy.zzz.125
127.0.0.0/8 dev lo scope link
192.168.13.0/24 dev eth0 proto kernel scope link src 192.168.13.1Something looks wrong with the eth1 settings but I can't put my finger on it. The default route associated with eth0 was, I'm certain, set by the setting in "/etc/rc.d/rc.inet1.conf".
I'm able to ping an internal workstation from the firewall, and the firewall from the workstation. I am able to ping the eth1 interface from the wifi connection on the Comcast router. Performing name resolution for internal hosts on the firewall works via the internal DNS. The internal DNS fails when trying to forward unknown hostnames to the my domain provider's DNS servers. When specifying Comcast's DNS servers first in /etc/resolv.conf on the firewall name resolution fails. (Well, I killed it after 4-5 sec.)
Thinking that this could be a lack of a route to the ISP's gateway, I tried adding that and got:
Code:root@fwallsys~# ip route add xxx.yyy.zzz.124/30 via xxx.yyy.zzz.126 gw dev eth1
Error: either "to" is a duplicate, or "gw" is a garbage
root@fwallsys~# ip route add xxx.yyy.zzz.124/30 via xxx.yyy.zzz.126 dev eth1
RTNETLINK answers: File existsNone of those answers are very informative though I suspect that the second one might have been complaining that it was trying to duplicate the existing for xxx.yyy.zzz.124. (Which, I assume, was created using the information for eth1 in "/etc/rc.d/rc.inet1.conf".) I've tried different things (preceding the network with -net, inet, and so forth) but "ip route" cryptically complained about all of them. (How, exactly, is this better than "route" again? :^/ )
Questions:
Do I need to set up the gateway for the eth1 interface? And how is this done using "ip route"? (I think this will solve the biggest problem I'm seeing.)
Now, about that "state UNKNOWN"...
The other thing that I really haven't been able to figure out is that the old ethernet card ("eth1" that didn't fail) shows up differently:
Code:root@fwallsys:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ff
root@fwallsys:~# ip link set eth1 down
root@fwallsys:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ff
root@fwallsys:~# ip link set eth1 up
root@fwallsys:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:06:2b:00:24:d3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether f0:b4:d2:0c:9f:55 brd ff:ff:ff:ff:ff:ffI have to admit that I cannot recall whether something like this "state UNKNOWN" message was seen when the firewall was running under Slackware 14.1. It also doesn't seem to have a major effect on the interface since I'm able to ping to the ISP gateway. (Plus it was able to update an initial 14.2 install to -current before I decided to trash it, re-install 14.2, and stick with that.)
More questions:
What would cause "eth1" to have this "UNKNOWN" state?
What does that even mean?
What could be preventing it from being in an "UP" state as "eth0" is?
Does it even matter? Is it just a bogus bit of information?
I've seen RedHat and Arch bug reports about this during searches but most of these are pretty old (2012 and 2013!).
Final question:
Is there more information I should post that would help?
A thousand TIAs...