Cannot telnet and/or connect on some IP

[phototoy_co]

The weird thing is that i CAN telnet to 10.37.2.16 but NOT on 10.37.2.17. Telnet is enable on .17 server. Also when i return the old Zentyal telnetting worked fine. It seems that it cannot resolve on specific IP? Firewall is set to allow ANY - ANY and set on top of the rules.

[christian]

Odd indeed.
I don't understand the very detail of your configuration but guess that when you say "try with old server" you mean replacing the one doing routing with another one (old one) with same feature / same IP.

For sure ping being only ICMP, being able to ping doesn't mean you can telnet.
This said, why can you telnet 10.37.2.16 but not 2.17 ? At this stage given you network layout, I would look closer at routes on each workstation / server inside your LAN (10.37.2.16, 2.17 & 129.37.2.35)

If my guess is wrong about the switch between new and old server using same IP, then it will reinforce the need to check twice routes.

Looking again at your drawing, I still don't understand if these grey boxes are switches of Zentyal servers. I would bet switches but not 100% sure and quite confused. I'll try to redraw it on my side and share my understanding but I'm not yet at the stage I can achieve it. Your 2 Zentyal servers share same IP ranges on internal interfaces, so I suppose this is not a "stack" of server with one being front-end but rather 2 servers side-to-side. Which one is the correct layout or is it something even different?

[phototoy_co]

oh it's a lanner. http://www.lannerinc.com/ its a computer where i install Zentyal with up to 8 LAN ports. It is the Zentyal server

[phototoy_co]

Odd indeed.
I don't understand the very detail of your configuration but guess that when you say "try with old server" you mean replacing the one doing routing with another one (old one) with same feature / same IP.

For sure ping being only ICMP, being able to ping doesn't mean you can telnet.
This said, why can you telnet 10.37.2.16 but not 2.17 ? At this stage given you network layout, I would look closer at routes on each workstation / server inside your LAN (10.37.2.16, 2.17 & 129.37.2.35)

If my guess is wrong about the switch between new and old server using same IP, then it will reinforce the need to check twice routes.

Looking again at your drawing, I still don't understand if these grey boxes are switches of Zentyal servers. I would bet switches but not 100% sure and quite confused. I'll try to redraw it on my side and share my understanding but I'm not yet at the stage I can achieve it. Your 2 Zentyal servers share same IP ranges on internal interfaces, so I suppose this is not a "stack" of server with one being front-end but rather 2 servers side-to-side. Which one is the correct layout or is it something even different?

 - I don't understand the very detail of your configuration but guess that when you say "try with old server" you mean replacing the one doing routing with another one (old one) with same feature / same IP. Exactly

[christian]

Is it something like below drawing ?

I obviously show 2 "cables" between each Zentyal and two "cables" between routing Zentyal and switch while there is only one (based on your previous explanation) with virtual IPs.

Splitting it for the logical view makes it, from my standpoint, clearer.
I also do not mention additional IPs

Could you please clarify IP on each Zentyal server because I made some guesses rather than reading your drawing that was representing same "view"

[phototoy_co]

Yes this is correct.

[christian]

The positive point is that we now share same understanding.
The rather negative one is that this is far beyond my knowledge as with such design, I don't understand how devices on LAN could reach .2.1 and .2.250 interface on each network. Although this is not your current question, it makes me very confused about this global network layout(*) and potential side effects regarding your telnet related problem.

Just in case some changes occurred between 3.0 and 3.2, and as your hardware provides multiple NIC, as a matter of debugging process, I would suggest to split 10.37.2.42 and 129.37.2.42 on two different NIC, connecting both to same switch.
It will allow to set FW rules for each interface and have better tracking while running traceroute to understand what's wrong. Once solve, you may go back to your current design.

(*) to me, device laying between 2 physical network must have IPs on different subnet for each interface except if you decide, which is to me very very strange, to handle specific route to devices that are "on the other side" on same subnet.