DNS-problem from orange zone to green zone

jonaskellens · 11-13-2009, 04:30 AM

I have an Endian firewall that connects a RED zone (internet), a GREEN zone (LAN) and a ORANGE zone (DMZ).

Interzone traffic is allowed, so GREEN can talk to ORANGE and visa versa.

I have a ClarkConnect-server that serves as DNS & DHCP-server on the GREEN zone : 192.168.1.5

I have a Nagios-server with fixed IP-address in the ORANGE zone: 192.168.2.20.

My laptop is a client on the GREEN network that receives an IP-address from the DHCP-server, ClarkConnect, namely 192.168.1.11.

On my laptop-client :

Code:

[jonas@jonas ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
domain jocan.local
search jocan.local
nameserver 192.168.1.5
[jonas@jonas ~]$ ping -c 4 clarkconnect.jocan.local
PING clarkconnect.jocan.local (192.168.1.5) 56(84) bytes of data.
64 bytes from clarkconnect.jocan.local (192.168.1.5): icmp_seq=1 ttl=64 time=2.38 ms
64 bytes from clarkconnect.jocan.local (192.168.1.5): icmp_seq=2 ttl=64 time=5.72 ms
64 bytes from clarkconnect.jocan.local (192.168.1.5): icmp_seq=3 ttl=64 time=6.51 ms
64 bytes from clarkconnect.jocan.local (192.168.1.5): icmp_seq=4 ttl=64 time=5.82 ms

--- clarkconnect.jocan.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3010ms
rtt min/avg/max/mdev = 2.389/5.113/6.515/1.603 ms
[jonas@jonas ~]$ ping -c 4 nagios.jocan.local
PING nagios.jocan.local (192.168.2.20) 56(84) bytes of data.
64 bytes from nagios.jocan.local (192.168.2.20): icmp_seq=1 ttl=63 time=11.0 ms
64 bytes from nagios.jocan.local (192.168.2.20): icmp_seq=2 ttl=63 time=9.28 ms
64 bytes from nagios.jocan.local (192.168.2.20): icmp_seq=3 ttl=63 time=3.22 ms
64 bytes from nagios.jocan.local (192.168.2.20): icmp_seq=4 ttl=63 time=4.39 ms

--- nagios.jocan.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3007ms
rtt min/avg/max/mdev = 3.223/7.002/11.098/3.281 ms

On the Nagios-server :

Code:

[root@nagios ~]# cat /etc/resolv.conf 
search jocan.local
nameserver 192.168.1.5
[root@nagios ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         192.168.2.1     0.0.0.0         UG    0      0        0 eth0
[root@nagios ~]# ping -c 4 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.

--- 192.168.1.5 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3043ms
[root@nagios ~]# ping -c 4 clarkconnect.jocan.local
ping: unknown host clarkconnect.jocan.local

On Endian, the gateway/firewall :

Code:

root@endian:~ # route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 br1
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
XX.22.XX.0     *               255.255.240.0   U     0      0        0 eth1
default         XX-22-XX-1.acc 0.0.0.0         UG    0      0        0 eth1

Eth0 (192.168.1.250) is connected to the br0
Eth2 (192.168.2.1) is connected to the br1
Eth1 is the WAN-interface

Why can't my Nagios-server reach the ClarkConnect-server ??
The default gateway is set correctly (192.168.2.1 = Endian). So when the DNS-server resides on network 192.168.1, then it should go through Endian, right ??

jschiwal · 11-13-2009, 05:45 AM

What is the reason for the bridges in the Edian firewall? A bridge joins network segments. You have a LAN network and a DMZ on different network subnets, not segments. Joining different networks is what routing does.

Suppose you wanted to bridge together a wireless and a wired device to join your wired LAN and wireless networks. (This example is taken from the Network Administrator's Guide 3rd Edition. You can get the 2nd edition on the www.tldp.org website)

# remove the ip addresses
ifcfg eth01 0.0.0.0 down
ifcfg wlan0 0.0.0.0 down

# add interfaces to be bridged
brctl addif br0 wlan0
brctl addif br0 eth1

Bridging is done at layer two, which uses the mac addresses. Adding an IP address to the bridge allows you to remotely manage the gateway host.

ifconfig br0 192.168.1.1 up
ifconfig wlan0 up
ifconfig eth0 up

Now if you had a third interface eth1, for the Internet connection, a common mistake would be to set up the routes before building the bridge. I suspect that may be your problem, but you shouldn't have bridges in the first place.

jonaskellens · 11-13-2009, 07:59 AM

Quote:

Originally Posted by jschiwal

What is the reason for the bridges in the Edian firewall?

Is the default configuration of Endian and the way Endian Firewall works.

It immediately creates a bridge for the GREEN & ORANGE network. Suppose you want to add a VLAN, a second GREEN lan, it's as easy (for Endian) as adding the VLAN to the bridge.

I cannot control this bridge-creation, but I am not opposed to it.

In my opinion, it is not these bridges that creates the problem.

jschiwal · 11-15-2009, 07:29 AM

If there were a bridge between the interfaces, you would have an IP address for the bridge and not the interfaces. This address would be for configuring the firewall and not for routing. You could have a bridge with no IP address on the bridge device or NIC devices. If this sounds like a switch, that's because a switch is a bridge which joins network segments.

Quote:

Eth0 (192.168.1.250) is connected to the br0
Eth2 (192.168.2.1) is connected to the br1
Eth1 is the WAN-interface

Also show how the bridges are setup. I looked in their website. They seem to use different subnets/network addresses between zones. This sounds like a router as I would expect and not bridge config. in see any advantage to having a bridge device as an alias for an ethernet device, which is what you seem to be describing.

A bridge that doesn't bridge anything sounds odd IMHO. How many ports does it have. It there are several ports that you can use to connect to a single zone, then you would bridge those NICs together. Perhaps they configure a bridge device for each zone so that you can add or remove particular interfaces on one zone or another. Then the routing and firewall rules would use bridge device names and not NIC names. Which zone a port is on would depend on which which bridge that device is attached to and the rules wouldn't need to be updated when ports are added or reassigned.

Run "brctl show" to show how the bridges are set up. Let's double check that the bridge is made up of the interfaces we think they are.
Run "ifconfig" to show the configurations of the interfaces and bridges.
Run "route" again to show the routing rules.

Also, why is the nagios server in the DMZ? Doesn't it monitor the condition of hosts on the LAN? I don't believe that the interfaces between the DMZ and LAN are bridged together. Whether you have connectivity between the nagios server and the LAN may be due to either the routing between the two bridges which seems OK from what you posted, or the firewall rules.

jonaskellens · 11-16-2009, 02:45 AM

Quote:

Originally Posted by jschiwal

If there were a bridge between the interfaces, you would have an IP address for the bridge and not the interfaces.

Code:

root@endian:~ # ifconfig
br0       Link encap:Ethernet  HWaddr 00:XX:XX:3D:D7:CB  
          inet addr:192.168.1.250  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:577946 errors:0 dropped:0 overruns:0 frame:0
          TX packets:723485 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:65220374 (62.1 MiB)  TX bytes:783864416 (747.5 MiB)

br1       Link encap:Ethernet  HWaddr 08:XX:XX:6E:B6:0B  
          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:553380 errors:0 dropped:0 overruns:0 frame:0
          TX packets:392838 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:129134297 (123.1 MiB)  TX bytes:46421533 (44.2 MiB)
eth0      Link encap:Ethernet  HWaddr 08:XX:XX:6E:66:F3  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:12070420 errors:32 dropped:0 overruns:0 frame:0
          TX packets:723498 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2586179308 (2.4 GiB)  TX bytes:783865894 (747.5 MiB)
          Interrupt:9 Base address:0xd060 

eth1      Link encap:Ethernet  HWaddr 08:XX:XX:23:60:14  
          inet addr:XX.22.XX.XX  Bcast:XX.22.XX.255  Mask:255.255.248.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:961942 errors:0 dropped:0 overruns:0 frame:0
          TX packets:631308 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:739559050 (705.2 MiB)  TX bytes:118599096 (113.1 MiB)
          Base address:0xd040 Memory:f0420000-f0440000 

eth2      Link encap:Ethernet  HWaddr 08:XX:XX:6E:B6:0B  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:553423 errors:0 dropped:0 overruns:0 frame:0
          TX packets:392842 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:139104330 (132.6 MiB)  TX bytes:46421869 (44.2 MiB)
          Base address:0xd080 Memory:f0520000-f0540000

Quote:

Originally Posted by jschiwal

Perhaps they configure a bridge device for each zone so that you can add or remove particular interfaces on one zone or another. Then the routing and firewall rules would use bridge device names and not NIC names. Which zone a port is on would depend on which which bridge that device is attached to and the rules wouldn't need to be updated when ports are added or reassigned.

As I said it in short : even with 1 GREEN interface, Endian already creates a bridge to be able to attach multiple NIC's together. You explain it in long version...

Quote:

Originally Posted by jschiwal

Also, why is the nagios server in the DMZ? Doesn't it monitor the condition of hosts on the LAN?

My Nagios monitors public servers on the internet which are widespread. I think therefore it belongs in the ORANGE zone.

Quote:

Originally Posted by jschiwal

I don't believe that the interfaces between the DMZ and LAN are bridged together.

They aren't.

Quote:

Originally Posted by jschiwal

Whether you have connectivity between the nagios server and the LAN may be due to either the routing between the two bridges which seems OK from what you posted, or the firewall rules.

If you say the routing seems OK, then I need to dig into the firewall of Endian to know why there is no traffic between ORANGE & GREEN.

jschiwal · 11-16-2009, 07:19 PM

From a previous post:

Code:

192.168.2.0     *               255.255.255.0   U     0      0        0 br1
192.168.1.0     *               255.255.255.0   U     0      0        0 br0

These are the routes between the LAN and DMZ. You could double check whether ip_forward forwarding is enabled. It probably is. Also check the kernel modules that are loaded. I had a similar problem with forwarding not working. It worked after I enabled the nf_conntrack_ipv4 kernel module. ( This module was named something else back then. ) I don't think this will be the case as other traffic is forwarded.

Again the Nagios server only has one interface, and the default gateway is set properly.

Other than that, check the firewall settings of the Endian firewall. Be sure to check the Endians logs. If you need to enable logging, do so and try reaching a host on the lan from the Nagios server. Check the Nagios Server's firewall setting as well. Maybe pings are being dropped but other traffic is forwarded. Determine a port that is open on a LAN host, and try using the telnet client: e.g. telnet 192.168.1.5 22. Try ports that the Nagios server will be using, e.g. for dns. Connect your laptop to the DNS port, configure it's interface & route appropriately and see if it can reach hosts on the LAN.