MNF Multi-Network Firewall Config Interface SNAFU

[Windependent]

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

[jleaman]

i use this firewall all the time.. when i get home ill try this..

 

Also are you trying example https://1.1.1.1:8443 Ip and port ?

 

The 1.1.1.1 is example it should be 192.168.1.10:8443

 

let me know if this helps or not..

 

 

Jason..

[Windependent]

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

[jleaman]

yes i have had that problem also so i went into the bios of the firewall and changed it in there to match mine : O) simple fix..

 

 

Is the firewall working now. : O ) ...?