Windependent

Red, thanks for the tip. it turns out that MNF will not allow logons from the other PC behind the firewall if the system clocks are not properly synchronized - practically speaking, the two clocks have to be in the same timezone, in addition to your criterion of having to be within an hour of each other. in my case, i had the MNF PC's system clock set to UTC, with the Linux clock set to the Eastern Timezone. this is the default setup that you get if you specify USA as your location during the MNF setup. the Client PC (9.2) had both the sytem clock and Linux Clock set to Central Time. although clocks on both PCs were set to the correct time for their respective timezones (and effectively synchronized), this created some issues in MNF. with the MNF linux clock running at (for example) 13:00 ET and the client Linux clock running at 12:00 CT, MNF will not authenticate a client logon request. that is to say, on the initial configuration it would let me log-on, but on subsequent log-ons MNF refused to proceed with authentication, solely becasue of discrepancies in the clocks. evidently, MNF only pays superficial attention to the linux clocks, and doesn't bother to normalize them (referenced to UTC) for their respective time zones. as a result, even though the software clocks may actually specify the correct time in each of two different zones, MNF can't handle the situation. for practical purposes, it was easier for me to change the system clock on the client machine running mandrake 9.2 (via KDE) than it would have been to reprogram the software clock on the MNF box via the command line. so i set the client PC from 12:00 CT to 13:00 ET. presto! MNF allowed the logon. i promptly used the MNF remote configuration tool from the client to change the MNF linux clock to the central time zone, and then set the client back to 12:00 CT via KDE. the logon would not work... examining the MNF box, the software-based changing of the clock to CT never "took." the box still reported the ET timezone. so i tried this again, resetting clocks on each PC to ET. on the second attempt MNF successfully changed the software clock via the browser interface on the client PC. now both PCs are running on Central Time without a hitch. everything appears to work beautifully. so i've identified a few problems: 1. MNF doesn't have very good timezone options on installation - I was forced into using ET and not given a choice on USA timezones 2. MNF won't allow "remote" logons (from behind the firewall) if the software clocks on the PCs are discrepant. the discrepancy can be caused by any number of criteria. 3. when attempting to program the MNF software clock from a client PC, you have to make multiple attempts to reset the clock, as sometimes the first attempt won't "take." 4. MNF mistakenly reports the time issues as cookie problems, which makes troubleshooting more difficult. I have no idea why situation 2 described above would be the case. I get the impression that this is a really weak attempt at a security measure, or it is an oversight in which the programmers only paid the most superficial attention to verifying time across the systems' software clocks. It appears as if they do bother to check the time, but don't bother to take into account all of the calculations that are necessary to do the job properly. PErhaps this was a programming shortcut. Perhaps it was an oversight. Either way, based on the posts I've seen here, alot of people have been hit by this "feature." If MNF were my product, I'd begin working on a fix. thanks again. bob

Jason, thanks for the help. yes, i've used the correct IP and port, without any luck. i was able to solve the problem, though. it turns out that MNF will not allow logons from the other PC behind the firewall if the system clocks are not properly synchronized - practically speaking, the two clocks have to be in the same timezone, and have to be within an hour of each other. in my case, i had the MNF PC's system clock set to UTC, with the Linux clock set to the Eastern Timezone. this is the default setup that you get if you specify USA as your location during the MNF setup. the Client PC had both the sytem clock and Linux Clock set to Central Time. although clocks on both PCs were set to the correct time for their respective timezones (and effectively synchronized), this created some issues in MNF. with the MNF linux clock running at (for example) 13:00 ET and the client Linux clock running at 12:00 CT, MNF will not authenticate a client logon request. that is to say, on the initial configuration it would let me log-on, but on subsequent log-ons MNF refused to proceed with authentication, solely becasue of discrepancies in the clocks. evidently, MNF only pays superficial attention to the linux clocks, and doesn't bother to normalize them (referenced to GMT or UTC) for their respective time zones. as a result, even though the software clocks may actually specify the correct time in each of two different zones, MNF can't handle the situation. for practical purposes, it was easier for me to change the system clock on the client machine running mandrake 9.2 (via KDE) than it would have been to reprogram the software clock on the MNF box via the command line. so i set the client PC from 12:00 CT to 13:00 ET. presto! MNF allowed the logon. i promptly used the MNF remote configuration tool from the client to change the MNF linux clock to the central time zone, and then set the client back to 12:00 CT via KDE. the logon would not work... examining the MNF box, the software-based changing of the clock to CT never "took." the box still reported the ET timezone. so i tried this again, resetting clocks on each PC to ET. on the second attempt MNF successfully changed the software clock via the browser interface on the client PC. now both PCs are running on Central Time without a hitch. everything appears to work beautifully. so i've identified a few problems: 1. MNF doesn't have very good timezone options on installation - I was forced into using ET and not given a choice on USA timezones 2. MNF won't allow "remote" logons (from behind the firewall) if the software clocks on the PCs are discrepant. 3. when attempting to program the MNF software clock from a client PC, you have to make multiple attempts to reset the clock, as sometimes the first attempt won't "take." I have no idea why situation 2 described above would be the case. I get the impression that this is a really weak attempt at a security measure, or it is an oversight in which the programmers only paid the most superficial attention to verifying time across the system clocks. It appears as if they do bother to check the time, but don't bother to take into account all of the calculations that are necessary to do the job properly. PErhaps this was a programming shortcut. Perhaps it was an oversight. Either way, based on the posts I've seen in the Security message board, alot of people have been hit by this "feature." If MNF were my product, I'd begin working on a fix. thanks again. bob

i'm no expert here, but am i correct in assuming that you want to enable network shares across the network to enable file and print service sharing between the Windows and Linux boxes? if that's the case, you need to do one of two things: 1. install a samba server on your linux box, or 2. install a nfs server on your linux box and nfs clients on your Win PCs i've recently done this with a Mandrake 9.2 box and a number of Win 98 boxes. one problem that I ran into was that Samba would not properly install as an add-on package to a system that had been previously set-up with linux. when performing a clean install from the CD though, 9.2 properly installed samba and networking with the Win PCs was a breeze. hth! bob

Red, thanks for your help. I'm not sure if you've seen my other posts or not, but in my original post on this topic (before I discovered your posts) I had mentioned that I thought that logon restrictions preventing a remote logon as root seemed like a good idea. I'm glad to hear that MNF seems to be designed in a way that makes sense. Regarding your two other explanations, I am certain that the presence of cookies is not the problem, as I'm not having any luck logging on from ANY of my machines on the LAN, in spite of the fact that they're regularly used for cookie-enabled web surfing. The idea about system times is interesting. Although I'm sure that I've reset the system time on these machines in the past few days, I'm not sure whether or not one of the machines may have the hardware system clock set to GMT, with the OS updating the software clock to local (central) time. I had thought that I had configured all of the hardware clocks to be set to local time, but now I remember that in the MNF setup, I wasn't asked about my local time zone -- I was only asked about my country location. For all I know, MNF could be assuming that its hardware is in the Eastern time zone. In contrast, under MDK 9.2 I was asked about my local time zone, and specified Central Time. IIRC, there was an option about GMT referencing of the hardware clock. Its conceivable that the discrepancy on the system clocks could be the source of the problem. I had thought that I had enabled time syncing on both systems. I'll have to check it out and get back to you. thanks!!!

i just had the same problem with my first installation of 9.2 -- the sound card was toggled off during installation. interestingly, the KDE splash screen played music during system initialization, and the soundcard was muted AFTERWARD. IMHO, turning the sound card off after making sound only serves to confuse the user. one other thing I have noticed -- on my dual boot windows system, the volume under Linux is markedly reduced. after setting levels under Linux, when I reboot the windows partition the volume is so loud that it sounds like the speakers are going to blow. can anyone explain this? tia! bob

Funny, I’ve just run into the exact same problem and it doesn’t seem to be an IE-specific “feature” of MNF. The same problem comes up on a fresh installation of MNF when used in conjunction with a fresh installation of 9.2. I’ve just installed each system on a pair of PCs. Upon completion of the MNF installation, MNF prompted me to create 3 user accounts: root, Admin, and a regular user account, which I optionally gave SU capabilities. Immediately after creating these accounts, I was instructed to log on to the administrator’s web interface from another local machine behind the firewall. So I walked over to the freshly configured installation of 9.2 that was running the KDE GUI 3.1.3 with Konqueror 3.1.4 as the browser. Using the web administration tool, I could not log onto the root account. I could also not log onto my user account. On the 5th attempt I was able to log onto the Admin account. I proceeded with configuration of the firewall without any apparent problems. About a half-hour later I tried logging back onto the web administrative tool from the same Mandrake 9.2 workstation running Konqueror. I could not log back onto the interface, and each attempt at authentication failed with the same “Session Not Found : No Cookies Found” error. I have verified that the cookies from the MNF server are actually on the disk. I’ve tried deleting them, and toggling the installation of cookies within the browser back and forth with no favorable results. Nothing that I can do at the client side seems to work. Fwiw, I’ve tried performing the same steps from a Win98 Client using IE 5.5 with cookies enabled and I get the same results. This definitely seems to be a problem with MNF, or as I like to call it, MFNF.

Hmm. I've run into a similar cookie problem. Immediately after configuring MNF, I tried to use the web admin tool to re-configure it, and all attempts at user authentication failed. I received a "Session not found : Cookies not found" error message. Fwiw, this happened both in IE 5.5 on a Win98 client, and on the same Konqueror session that was used only minutes earlier to configure the firewall. This is not an IE-specific problem. Were you able to work around it with Netscape?

i have a similar problem -- right after configuring MNF, the web config tool broke. the first time i used it i was able to configure the firewall. 10 minutes later i tried to log back on from the same session on a client to make a change, and i received a "No Session Found : Cookies not found" error. Check out the thread entitled "MFN Config SNAFU." bob

I’m new to the board and this is my first post. I have a problem with setup of the Mandrake MNF and I’m hoping that someone here can provide some insight. After too many years of being held hostage by MSFT, I’ve made the decision to learn Linux. I’ve started off running Mandrake 9.2 on a 2 PC test platform. I’ve spent a solid week with the new OS, and using the RTFM approach I’ve succeeded in configuring both NFS and SMB to enable cross-platform networking between the Linux boxes and a Windows SMB network on a tiny fast-ethernet LAN in my home. The next logical step seems to be establishing a good firewall before the LAN is connected to the outside world via DSL. Instead of going with a low-end solution like one of the low-cost black-box broadband routers that won’t support stateful packet routing and VPN tunneling, I’ve opted to go for a more configurable PC-based firewall. As an experiment, I’ve successfully downloaded and installed the Mandrake MNF on a Pentium-class machine that will act as a firewall, serve DHCP, perform NAT, etc. MNF seems to have installed properly – although the installation program used a GUI-based interface, the MNF software boots to a console (no GUI). I’m assuming that this is normal, and that the MNF normally boots to console to avoid the overhead associated with a GUI. Please correct me if I’m wrong on this. Upon completion of the installation you’re invited to configure MNF. To do this you’re supposed to open a browser on one of the local machines behind the firewall and enter the following firewall’s URL: "https:/localhost.localdomain:8443/”. This loads an HTML-based configuration page that is used to configure the MNF. When loading the configuration page, I was rejected during authentication when attempting to log-on using the root user-ID, and my personal user-ID that was set-up with SU capability. (Thinking about the desirability of gaining root status via a net connection, this seems to be a good idea). I was successful in logging on using the “Admin” user-ID, and proceeded to configure the MNF without any problems. Upon initial testing, the firewall appears to be working, along with the DHCP server, Squid transparent proxy, etc. So here’s the problem: I’ve decided that I probably won’t need Squid, so I want to re-configure the MNF. Unfortunately I can’t change/update the configuration of the MNF. When I attempt to re-load the HTML-based configuration page, authentication fails and I get kicked out. I’ve tried logging on using the Admin username and password, and instead of being authenticated, I receive the following error on the HTML page: “No Session Found : Cookies Not Found.” Session cookies are indeed enabled on the Mandrake 9.2 client with the same default settings that were initially used to configure the MNF: cookies enabled, session cookies enabled, force all cookies to session cookies disabled. Examination of the cookie list on my client PC from within KDE shows that there is indeed a cookie file from the server. Deleting and/or restoring the cookie doesn’t help. Interestingly, when I attempt to log onto the MNF from any of the Windows based PCs which have cookies enabled, I get the same results: “No session found : no cookies found.” If anyone has any recommendations or insights about this problem, I’d greatly appreciate your help. Unfortunately, with the download edition of MNF the documentation is not included, making the RTFM approach somewhat problematic. I’ve exhausted all of the HOWTO’s I could find, and I’m hoping that someone here may have an idea. Thanks for your time. Bob (Sorry for the double post)

I’m new to the board and this is my first post. I have a problem with setup of the Mandrake MNF and I’m hoping that someone here can provide some insight. After too many years of being held hostage by MSFT, I’ve made the decision to learn Linux. I’ve started off running Mandrake 9.2 on a 2 PC test platform. I’ve spent a solid week with the new OS, and using the RTFM approach I’ve succeeded in configuring both NFS and SMB to enable cross-platform networking between the Linux boxes and a Windows SMB network on a tiny fast-ethernet LAN in my home. The next logical step seems to be establishing a good firewall before the LAN is connected to the outside world via DSL. Instead of going with a low-end solution like one of the low-cost black-box broadband routers that won’t support stateful packet routing and VPN tunneling, I’ve opted to go for a more configurable PC-based firewall. As an experiment, I’ve successfully downloaded and installed the Mandrake MNF on a Pentium-class machine that will act as a firewall, serve DHCP, perform NAT, etc. MNF seems to have installed properly – although the installation program used a GUI-based interface, the MNF software boots to a console (no GUI). I’m assuming that this is normal, and that the MNF normally boots to console to avoid the overhead associated with a GUI. Please correct me if I’m wrong on this. Upon completion of the installation you’re invited to configure MNF. To do this you’re supposed to open a browser on one of the local machines behind the firewall and enter the firewall’s URL: "https:/localhost.localdomain:8443/”. This loads an HTML-based configuration page that is used to configure the MNF. When loading the configuration page, I was rejected during authentication when attempting to log-on using the root user-ID, and my personal user-ID that was set-up with SU capability. (Thinking about the desirability of gaining root status via a net connection, this seems to be a good idea). I was successful in logging on using the “Admin” user-ID, and proceeded to configure the MNF without any problems. Upon initial testing, the firewall appears to be working, along with the DHCP server, Squid transparent proxy, etc. So here’s the problem: I’ve decided that I probably won’t need Squid, so I want to re-configure the MNF. Unfortunately I can’t change/update the configuration of the MNF. When I attempt to re-load the HTML-based configuration page, authentication fails and I get kicked out. I’ve tried logging on using the Admin username and password, and instead of being authenticated, I receive the following error on the HTML page: “No Session Found : Cookies Not Found.” Session cookies are indeed enabled on the Mandrake 9.2 client with the same default settings that were initially used to configure the MNF: cookies enabled, session cookies enabled, force all cookies to session cookies disabled. Examination of the cookie list on my client PC from within KDE shows that there is indeed a cookie file from the server. Deleting and/or restoring the cookie doesn’t help. Interestingly, when I attempt to log onto the MNF from any of the Windows based PCs which have cookies enabled, I get the same results: “No session found : no cookies found.” If anyone has any recommendations or insights about this problem, I’d greatly appreciate your help. Unfortunately, with the download edition of MNF the documentation is not included, making the RTFM approach somewhat problematic. I’ve exhausted all of the HOWTO’s I could find, and I’m hoping that someone here may have an idea. Thanks for your time. Bob