Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Control » Problem with Apple devices and DHCP
  •  
ERTW

Messages: 2
Karma: -1
Send a private message to this user
Greetings, everyone.
Some help/insight/suggestions for a work-around to this Apple and Kerio Control 7.4.2 build 5136 issue would be much appreciated:


Apple devices (iPhones, iPads) keep declining IP address leases specifically reserved for them... even though there are no conflicts / no other devices on the LAN using those addresses! (Aside: Every non-Apple device that has ever connected to the LAN has never had a DCHP DECLINE incident... so I'm tempted to put the blame squarely on Apple for this one.)

But regardless of who at Apple screwed this up, I still need to find a work-around. (Much as I'd like to, I can't simply tell the Apple users to dump their junk and get something that works properly.)

I even tried adding several DHCP reservations (by MAC address and by hostname) for each Apple device, with each redundant reservation having a unique IP address. (So if it declines one, it can at least take a known alternate "backup" IP address.) But after the first DHCP DECLINE (that I noticed), Kerio Control fell back to offering a random IP address instead of one of the remaining reservations! (Either this is the fault of Kerio's programmers, or all the other redundant reservations had already been marked DECLINED before I began investigating.)

Furthermore, after enabling the Debug Log and looking at the DHCP messages, it appears that often the Apple devices will decline several of the random IP address offers too, before finally settling down and accepting something.

As a further annoyance, the only way I was able to clean out the declined IP addresses after Apple pissed in the pool was to shut down Kerio control and then manually edit the file Leases.cfg before restarting. (I was not going to wait-out the 86400 seconds that a reservation remains marked "DECLINED"; that's WAY too long! Anyhow, not only does restarting interrupt service for everyone & everything, it also resets the Daily and Weekly data counters! Shame on Kerio's programmers for this defect!)

Then I found this hack: Edit the WinRoute.cfg file and modify the <variable name="DeclineTimeout">86400</variable> entry (within <table name="DHCP"> ) to 0 seconds (instead of the default 86400). That solved the problem of a poisoned DHCP pool; reservations no longer become off-limits after being declined! But now there's a new problem: Apple devices take about 15 ~ 20 minutes to eventually accept their IP address, after flooding the network with a packet-storm of hundreds of DHCP DECLINE, DISCOVER, REQUEST packets (which of course elicit hundreds of DHCP OFFER and ACK replies)!

I have zero pity for the sheep who claim Steve Jobs is God and their iPhone is the Holy Grail, and now complain about the 20-minute connect times on this network. But I do pity the unfortunate people who didn't realize what they got themselves into when they bought their iPhone. And I get irritated at the drop in network performance due to the Apple-instigated DHCP packet storms.


What should I do? What can I do?

I can't move on to a later version of Kerio Control, because as far as I know, 7.4.2 build 5136 was the last one to run under Windows.


Some further info, for the curious:

I have Kerio Control running on an IBM IntelliStation E Pro running Windows XP Pro.

The computer has 3 network interfaces -- its onboard Ethernet, an Ethernet PCI card that was later installed, and a TP-Link N600 USB Wi-Fi adapter.

The PCI card is used as the WAN uplink; it's working fine, no problems.

The TP-Link N600 is configured to act as an "Access Point" using TP-Link's lousy provision software. Although TP-Link's garbage normally tries to activate Windows Internet Connection Sharing (whether you like it or not!), I deleted it's "helper" IcsManager.exe program to prevent this from happening. (I replaced it with a "do nothing" program I made and compiled as IcsManager.exe, so TP-Link's over-assuming software doesn't bark and complain. Problem averted.)

I then used Windows XP's "Network Bridge" feature to bridge the onboard Ethernet interface with the TP-Link N600 USB Wi-Fi interface, and set this bridge to be the "LAN interface" for Kerio Control. (That way, LAN devices can connect by Wi-Fi or wired.)

[Updated on: Fri, 25 August 2017 05:32]

  •  
fishtech

Messages: 620
Karma: 14
Send a private message to this user
Kerio Control 9.x installed here.

All clients are MacOS/iOS. About 50 addresses are reserved. The problem you describe has never been experienced here.

Control has been running for 5 years or so... can't remember what version we started on.

ft..

[Updated on: Thu, 31 August 2017 15:40]

  •  
ERTW

Messages: 2
Karma: -1
Send a private message to this user
This IBM IntelliStation E Pro w. Kerio Control 7.4.2 b5136 and Win XP Pro has been running continuously for 4 years. This problem never became apparent until recently.

It should be noted, however, the "Network Bridge" was a recent change in configuration. Originally the TP Link N600 and the computer's onboard Ethernet interface were on separate subnets. This allowed network software to immediately determine if a LAN client was using Wi-Fi or using wired Ethernet, just by looking at its IP address subnet. But it was an administrative pain because each client required two DHCP reservations (one for each interface).

Then we got some network software that relied on IP broadcasts, which of course could not cross through from one subnet to the other. That forced a change in configuration from two subnets to a single subnet and bridging the two LAN interfaces.

It was shortly after this change that the DHCP problem surfaced. BUT...

...At the same time the IP addressing plan was changed, we also got a huge wave of new users bringing in their own equipment! So I can't say for sure if it was the Win XP Network Bridge and single-subnet that triggered the problem, or if it was the wave of new iPhones and new iPads that are responsible for this issue.

I am still leaning towards criticizing Apple for it though, because none of the non-Apple clients that were still retained seemed to have any problem even after we changed the network to its single-subnet plan. And none of the new users who arrived with Android, Windows 7, and Windows 10 equipment have had any problems. And none of our long-time users (who may or may not be using Apple stuff) reported any problems. (It was only the new users that alerted us they couldn't get access to some network services; it was then that we discovered their devices were not being assigned the proper reserved IP addresses.)
Previous Topic: IPS Update error
Next Topic: WebInterfaceSSL limit reached
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Tue Sep 26 09:29:21 CEST 2017

Total time taken to generate the page: 0.00386 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.