Forum Replies Created
This is most curious… had no issues on my laptop, so I assumed it was the server’s hardware…
Booted ZS on the server again, but using option 2 (verbose – or something liek it) to see what was up… it worked flawlessly…
Rebooted again in normal mode, and this time paid attention to what was happening… the x.509 certificate for admin failed to generate, which in turn meant LDAP never worked and as such the DNS server as well threw a hissy fit…
Reboot in mode 2; and all is happy… how very curious…
Couldn’t get ZS to get a dynamic IP from my ISP though, but I’ve had enough for a day… going out now!
Enjoy your weekend.
You probably know about the Setup–>https tab–>Allow access only from (IP or subnet) settings. Of course, if these get set wrong, you can’t get in to fix it.
Have you tried this: (from the FAQ)
Having incorrectly configured the firewall or the network in general I can no longer connect via the web interface. Even rebooting the system doesn’t work. How can I resolve the problem?
From the ZeroShell console press the Z key. This enables the system to start the Fail-Safe procedure: you will be requested to select an Ethernet interface which can be attributed an IP address of your choice; any obstacles, such as firewall rules, belonging to a bridge, static routes or other will be removed. Once complete, you can access the interface via the IP address you attributed. To exit the Fail-Safe mode you must reboot, having removed the obstacle that blocked access.
This is my first whack at ZS, so I’ve never even seen the web-interface!
Sorry for the late reply, had a client who had a virus outbreak and ended up spending a while on site away from home…
Below is the dump from nmap – I don’t see anything on port 443… (oh, and I’ve tried reburning the disk).
The network connection definetly works, I could ssh/scp from the ZS box to my laptop to grab the nmap file…
So my three options:
– Server hardware is the issue (Dell 1u something-or-other) (most unlikely)
– Laptop is the issue (windows Vista… so quite possible it doesn’t like something. I did notice the scp took longer than it should have, so possibly it’s timing out before ZS responds…)
– ZS software (very unlikely as it works for everyone else and it a clean burn, verified, with no changes to the config)
Hmm… I’m confused…
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN 1629/slapd
tcp 0 0 0.0.0.0:749 0.0.0.0:* LISTEN 4044/kadmind
tcp 0 0 127.0.0.1:389 127.0.0.1:59945 TIME_WAIT -
tcp 0 0 127.0.0.1:59948 127.0.0.1:389 TIME_WAIT -
tcp 0 0 127.0.0.1:389 127.0.0.1:59946 TIME_WAIT -
tcp 0 0 127.0.0.1:59947 127.0.0.1:389 TIME_WAIT -
udp 0 0 0.0.0.0:464 0.0.0.0:* 4044/kadmind
udp 0 0 192.168.142.142:88 0.0.0.0:* 4041/krb5kdc
udp 0 0 192.168.250.254:88 0.0.0.0:* 4041/krb5kdc
udp 0 0 192.168.0.75:88 0.0.0.0:* 4041/krb5kdc
udp 0 0 192.168.142.142:750 0.0.0.0:* 4041/krb5kdc
udp 0 0 192.168.250.254:750 0.0.0.0:* 4041/krb5kdc
udp 0 0 192.168.0.75:750 0.0.0.0:* 4041/krb5kdc
udp 0 0 192.168.250.254:123 0.0.0.0:* 3978/ntpd
udp 0 0 192.168.141.142:123 0.0.0.0:* 3978/ntpd
udp 0 0 192.168.0.75:123 0.0.0.0:* 3978/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 3978/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 3978/ntpd
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ] DGRAM 190 941/udevd @/org/kernel/udev/udevd
unix 7 [ ] DGRAM 2250 1713/syslogd /dev/log
unix 2 [ ] DGRAM 5423 4151/cron
unix 2 [ ] DGRAM 5108 4044/kadmind
unix 2 [ ] DGRAM 5089 4041/krb5kdc
unix 2 [ ] DGRAM 4914 3978/ntpd
unix 2 [ ] DGRAM 2293 1722/klogd
EDIT: Oh, and yes I had tried the failsafe mode…and have tried again…
EDIT2: rebooted into OsX just to see if it was indeed vista… still can’t get anywhere… running OsXs built in portscan (which frankly is quite crappy) I get only 749 open.
Port Scan has started ...
Port Scanning host: 192.168.0.75
Open TCP Port: 749 kerberos-adm
Port Scan has completed ...
Next, I’m going to eliminate the server hardware… going to try with a second laptop running ZS… if I still can’t connect, then it’s either the switch (an old 48-port AT switch) or the cables…
There is a monitor connected, that’s how I can ping my client from ZS… Doing an ifstat shows that 192.168.0.75 is assigned to ETH00:00 which seems to be right…
Very, very weird…
Will try burning the disk again tomorrow, I’m thinking maybe something got screwed in the download/burn process…. I’ve got to get to bed, have a client tomorrow that’s quite far from where I live, so it’s an early wakeup for me!
update… just did a portscan on the server, and all I’m getting open is 749, which is for Kerberos… port 80 (http) and port 443 (https) don’t respond as open….
Now I’m confused, as it seem like I’m the only person to get this problem!
Am I doing something wrong?