Topic: Changed subnets - can't access server

[bcalder01]

I am running a 7.4 server in server-only mode. Everybody was on the 192.168.1.0 network when I originally created the server, and all was well. Recently we enabled VLANs, and now my administrative machine is on the 192.168.10.0 subnet. I can no longer reach the server - I get a 403 "You don't have permission to access /server-manager on this server." error. I can still access from the .1.0 subnet, but how do I allow the .10 subnet as well?

Apologies for what is probably an easy noobie question, and thanks in advance.

[bcalder01]

I should add that in order to try to utilize the new subnets, I had gone into server reconfiguration & changed the subnet from 255.255.255.0 to 255.255.0.0. My 80+ Window users lost connection to the server & couldn't synchronize, even after restarts (server & workstation), until I changed the subnet back to 255.255.255.0.

[CharlieBrady]

Recently we enabled VLANs, and now my administrative machine is on the 192.168.10.0 subnet. I can no longer reach the server - I get a 403 "You don't have permission to access /server-manager on this server." error.

So you *can* reach the server, but you don't have permission to access the server-manager. Your new LAN hasn't been noted as a "local network" in SME's server manager.

[bcalder01]

Thank you - I was able to connect via the original subnet & added the new VLANs.

[bcalder01]

I am still experiencing weird issues with the SME server, in which connection attempts are timing out from one VLAN to another. It is happening from machines on the server's VLAN as well (192.168.1.0), but not consistently. My machine is on the 192.168.10.0 subnet, I have added 192.168.10.0 to the local networks in Control Panel, and so I can access machines on the server's VLAN as well as my own VLAN, but attempts to the file server itself are going all over the place - 27 hops! Here are traceroutes to 1) a machine on my .10 subnet, 2) a server on the .1 subnet, and 3) to the SME server, en-fs01:

-------------------------------------------------------------------------------------------------------------------------------------------------------------
1) bcalder@en-087:~$ traceroute 192.168.10.49
traceroute to 192.168.10.49 (192.168.10.49), 30 hops max, 40 byte packets
 1  flbox.local (192.168.10.49)  1.885 ms  1.873 ms  1.866 ms

2) bcalder@en-087:~$ traceroute 192.168.1.249
traceroute to 192.168.1.249 (192.168.1.249), 30 hops max, 40 byte packets
 1  192.168.10.1 (192.168.10.1)  1.554 ms  2.787 ms  4.048 ms
 2  en-net01 (192.168.1.249)  7.520 ms  7.674 ms  7.744 ms

3) bcalder@en-087:~$ traceroute 192.168.1.240
traceroute to 192.168.1.240 (192.168.1.240), 30 hops max, 40 byte packets
 1  192.168.10.1 (192.168.10.1)  1.407 ms  2.700 ms  3.956 ms
 2  * * *
 3  * * *
-- snip --
27  * * en-fs01 (192.168.1.240)  2.381 ms
------------------------------------------------------------------------------------------------------------------------------------------------------------ 

We have a Linux box set up on the .1 subnet as the DNS caching & WINS servers (the second traceroute). In Control Panel - Domains, I have identified the server as the corporate DNS server, but confusingly in Review Configuration - Server Names, the SME server still lists itself as the DNS server.

I am working with another tech on this, and neither of us really understand from the documentation how we might modify the related templates (part of the reason we set up another DNS/WINS  server).

Any help to get to the bottom of this would be greatly appreciated.

[CharlieBrady]

I am still experiencing weird issues with the SME server, in which connection attempts are timing out from one VLAN to another.

Your router is responsible for moving packets from one VLAN to another and back. Nothing to do with SME server.

[mercyh]

What Charlie says is true.

The question is why does the NON SME machine on the same subnet resolve with 2 hops while the SME has 27 hops.

One thing you might try, temporarily put the SME on 192.168.1.249 and the "other" server on 192.168.1.240 and try your traceroute. This should tell you if it is misconfigured switches/router.

[CharlieBrady]

What Charlie says is true.

The question is why does the NON SME machine on the same subnet resolve with 2 hops while the SME has 27 hops.

One thing in the SME server configuration could affect moving packets back to a different network. If the wrong router address is entered in the remove networks panel, then additional hops will be added to outgoing traffic.

The same would apply if static routes are configured on any other equipment. If they are configured wrongly, then packets won't go whether they are intended to go.

[mercyh]

The same would apply if static routes are configured on any other equipment. If they are configured wrongly, then packets won't go whether they are intended to go

.

that is exactly what I hoped could be tested by switching the IP addresses. If it is an SME setting the problem will remain with the SME on the new address.

If the problem stays with the 192.168.1.240 IP address on the new server it "must" be misconfigured on "other" equipment.

[bcalder01]

Thanks all for the replies.

I will try the IP swap suggestion after working hours, but it seems to be related to the server (BTW, it's a Dell PowerEdge T300 - any known issues with it??). Whether I ping it from the .1 or the .10 subnets, I get a 10 second or so hesitation, then 6-10 pings, hesitation again, etc. Pinging .1 or .10 addresses from the server yields much the same, but I'm actually getting slightly better time when pinging the other (.10) subnet!!

When I ping any machine, .1 or .10, from my workstation on .10, I get times of about 0.4ms. Here's a ping of the SME server:
--------------------------------------------------------------------------------------------------
bcalder@en-087:~$ ping 192.168.1.240
PING 192.168.1.240 (192.168.1.240) 56(84) bytes of data.
64 bytes from 192.168.1.240: icmp_seq=1 ttl=63 time=0.416 ms
64 bytes from 192.168.1.240: icmp_seq=2 ttl=63 time=0.392 ms
64 bytes from 192.168.1.240: icmp_seq=3 ttl=63 time=0.429 ms
64 bytes from 192.168.1.240: icmp_seq=4 ttl=63 time=0.397 ms
64 bytes from 192.168.1.240: icmp_seq=5 ttl=63 time=0.386 ms
64 bytes from 192.168.1.240: icmp_seq=6 ttl=63 time=0.429 ms
64 bytes from 192.168.1.240: icmp_seq=7 ttl=63 time=0.432 ms
64 bytes from 192.168.1.240: icmp_seq=8 ttl=63 time=0.477 ms
64 bytes from 192.168.1.240: icmp_seq=9 ttl=63 time=0.411 ms
64 bytes from 192.168.1.240: icmp_seq=10 ttl=63 time=0.413 ms
64 bytes from 192.168.1.240: icmp_seq=11 ttl=63 time=0.395 ms
64 bytes from 192.168.1.240: icmp_seq=12 ttl=63 time=0.418 ms
64 bytes from 192.168.1.240: icmp_seq=13 ttl=127 time=37.7 ms
64 bytes from 192.168.1.240: icmp_seq=14 ttl=127 time=38.3 ms
64 bytes from 192.168.1.240: icmp_seq=15 ttl=127 time=38.0 ms
64 bytes from 192.168.1.240: icmp_seq=16 ttl=127 time=38.7 ms
64 bytes from 192.168.1.240: icmp_seq=17 ttl=127 time=38.4 ms
64 bytes from 192.168.1.240: icmp_seq=18 ttl=127 time=38.3 ms
64 bytes from 192.168.1.240: icmp_seq=19 ttl=127 time=38.0 ms
64 bytes from 192.168.1.240: icmp_seq=20 ttl=127 time=38.5 ms
64 bytes from 192.168.1.240: icmp_seq=21 ttl=127 time=37.8 ms
64 bytes from 192.168.1.240: icmp_seq=22 ttl=127 time=38.5 ms
64 bytes from 192.168.1.240: icmp_seq=23 ttl=127 time=38.2 ms
64 bytes from 192.168.1.240: icmp_seq=24 ttl=127 time=37.8 ms
--------------------------------------------------------------------------------------------------
Fine for a dozen pings, then suddenly almost 40 ms times.

We feel there's some process running on the server that's interfering with the networking, but danged if we can find it.

The server has two integrated Broadcom NetXtreme BCM5722 NICs. Don't think there's any known issues with them.

[bcalder01]

Actually I take that last statement back - I didn't realize the SME 7.4 kernel was so old. It seems possible it might be an issue with the NIC - I will try installing a Realtek-based one (DLink DGE-528T - r8169 driver, I think).

[mercyh]

I have several running with Broadcoms without a problem. Not with the network complexity you are dealing with though.

Did you check the Router in the remote networks panel to see if it was correct?

[Stefano]

The server has two integrated Broadcom NetXtreme BCM5722 NICs. Don't think there's any known issues with them.

are you using the two interfaces in bonding?

can you please send the output of

Code: [Select]

ifconfig

Thank you

Ciao
Stefano

[bcalder01]

Hi Stefano, I am only using one of the NICs (tho the bonding module is loaded). Here's the output of ifconfig:

------------------------------------------------------------------------------------------------------------------
eth0      Link encap:Ethernet  HWaddr 00:1E:C9:EC:27:51 
          inet addr:192.168.1.240  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:282580 errors:0 dropped:0 overruns:0 frame:0
          TX packets:160699 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:48844058 (46.5 MiB)  TX bytes:39973724 (38.1 MiB)
          Interrupt:169

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:45838 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45838 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4000057 (3.8 MiB)  TX bytes:4000057 (3.8 MiB)
------------------------------------------------------------------------------------------------------------------

[bcalder01]

Problem found ... it was a duplicate IP address (pause to wipe egg off face).

After testing the server with a Dlink card and a live CD, which worked fine, I thought, "Hold it-it just CANT be the NIC"! I shut the server down & pinged its address - and got replies, this time WITHOUT the lost packets. I finally traced the culprit down to an Avaya PBX that my predecessor had installed (with no documentation, natch). I changed the IP of the file server, and all is peachy.

Thanks to everyone for the help in resolving this - time for a cold one!