[SOLVED] New server, 2 NICs, 2 Subnets, Cant ping?

Sezotove · 03-12-2014, 03:17 PM

Okay so here is the problem! I got a Centos 6.5 server that im runnin an Openfire service on. It has dual nics.

Code:

                                                       -------- .2 machines
                                                       |
        eth0 2.222 ----------------------------- .2 swtich 
Server
        eth1 3.222 ----------------------------- .3 switch
                                                       |
                                                        -------- .3 machines

Now the machines on each respective subnet can ping the machine, but not cross subnet ping. ie .2.xxx machine ping .3.222 and visa versa.

GATEWAY is set to as 192.168.2.7(our FW) in the /etc/sysconfig/network.

Code:

DEVICE=eth0
HWADDR=00:14:38:EE:5B:BC
TYPE=Ethernet
UUID=6244e3fb-5a60-4b3f-9ec0-6bfb01d2eddc
IPADDR=192.168.2.220
NETMASK=255.255.255.0
DNS1=192.168.2.2
ONBOOT=yes
BOOTPROTO=static

Code:

DEVICE=eth1
HWADDR=00:14:38:EE:4B:C2
TYPE=Ethernet
UUID=30c3f089-b9ea-4634-b53c-d8580629b204
IPADDR=192.168.3.220
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=static

route-eth0(probably wrong)

Code:

192.168.3.0/24 via 192.168.3.220 dev eth1

ipv4 IP Forward is set to "1".

So any ideas?

kkoene · 03-12-2014, 03:35 PM

What is the output if you run a traceroute from one machine to another?

Sezotove · 03-12-2014, 03:50 PM

192.168.2.115(My local ubuntu box) ----> 192.168.3.220(The server in question eth1)

Code:

 1  [Our FW] (192.168.2.12)  0.398 ms  0.385 ms  0.375 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *

My machine to 192.168.2.220(server in question eth0)

Quote:

1 192.168.2.220 (192.168.2.220) 0.307 ms 0.296 ms 0.288 ms

A .3 windows server to 3.220

Quote:

Tracing route to 192.168.3.220 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.3.220

Trace complete.

.3 Windows server to 2.220

Code:

Tracing route to 192.168.2.220 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.3.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.

Ser Olmy · 03-12-2014, 04:11 PM

Quote:

Originally Posted by Sezotove

192.168.2.115(My local ubuntu box) ----> 192.168.3.220(The server in question eth1)

Code:

 1  [Our FW] (192.168.2.12)  0.398 ms  0.385 ms  0.375 ms
 2  * * *

To get from 192.168.2.0/24 to 192.168.3.0/24, 192.168.2.222 must be used as a gateway. Your system is using 192.168.2.12 as a gateway, and that router/firewall doesn't seem to know how to reach 192.168.3.0/24.

Change the gateway to 192.168.2.222 for hosts on the 192.168.2.0/24 network (except the 192.168.2.222 router itself, of course), or add a route on 192.168.2.12 to 192.168.3.0/24 via 192.168.2.222.

Sezotove · 03-12-2014, 04:15 PM

Quote:

Originally Posted by Ser Olmy

To get from 192.168.2.0/24 to 192.168.3.0/24, 192.168.2.222 must be used as a gateway. Your system is using 192.168.2.12 as a gateway, and that router/firewall doesn't seem to know how to reach 192.168.3.0/24.

Change the gateway to 192.168.2.222 for hosts on the 192.168.2.0/24 network (except the 192.168.2.222 router itself, of course), or add a route on 192.168.2.12 to 192.168.3.0/24 via 192.168.2.222.

2.12 and 3.1 are the same machine they are a firewall. 2.222/3.222 is the Openfire chat server.

Ser Olmy · 03-12-2014, 04:32 PM

So you have:

two networks, 192.168.2.0/24 and 192.168.3.0/24
a router/firewall with the addresses 192.168.2.12 and 192.168.3.1
and a server with two NICs and one IP address in each network (192.168.n.220), which is configured to use yet another gateway (192.168.2.7)?

At the very least, this will result in asymmetric routing. Connections from 192.168.2.115 to 192.168.3.220 will follow this path:

Code:

192.168.2.115 -> 192.168.2.12 -> 192.168.3.220

...while the return path looks like this:

Code:

192.168.3.220 -> 192.168.2.115

The state engine in the firewall is not likely to be amused, as it only sees half of the conversation.

Why are you connecting to 192.168.3.220 from 192.168.2.115, when the server has an IP address in the 192.168.2.0/24 network? Or rather, why make a dual-homed server when you're only using one of the connections?

Sezotove · 03-12-2014, 04:43 PM

Quote:

Originally Posted by Ser Olmy

So you have:

two networks, 192.168.2.0/24 and 192.168.3.0/24
a router/firewall with the addresses 192.168.2.12 and 192.168.3.1
and a server with two NICs and one IP address in each network (192.168.n.220), which is configured to use yet another gateway (192.168.2.7)?

At the very least, this will result in asymmetric routing. Connections from 192.168.2.115 to 192.168.3.220 will follow this path:

Code:

192.168.2.115 -> 192.168.2.12 -> 192.168.3.220

...while the return path looks like this:

Code:

192.168.3.220 -> 192.168.2.115

The state engine in the firewall is not likely to be amused, as it only sees half of the conversation.

Why are you connecting to 192.168.3.220 from 192.168.2.115, when the server has an IP address in the 192.168.2.0/24 network? Or rather, why make a dual-homed server when you're only using one of the connections?

The above is correct. 2.7 is our main FW for internet and the .2 subnet. 2.12/3.1 is the fw for the other side of the office. I connect to the server via 2.220 and the other side of the office connects via 3.220 which is what I want and it works fine. Im curious as to why I can hit all of my other dual nic/.3 only server but not this one. Now I did not set the other servers up and have looked and looked and can not find a definitive answer.

The thing im really trying to accomplish here is to allow all .3 users see the webapp for Spark(client for Openfire) which is hosted at 192.168.2.220/[rest of the domain].

Ser Olmy · 03-12-2014, 04:56 PM

Your network is a mess. Sorry, but that's the truth.

If you want to find out exactly why you can't connect from this particular host (192.168.2.115) to 192.168.3.220, use tcpdump to inspect the traffic in real time. Expect to see a mix of asymmetric routing, ICMP redirects and packets being rejected by a state filter.