Smoothwall BYOD - guests stop being able to talk to the Smoothie

[Primus]

It's how I've got it setup here, apparently it's best practice to have a DC conduct the 802.1x stuff as it reduces network traffic... As long as Accounting goes to the Smoothwall, it works fine.

 

I think you might be better off having NPS on its own VM ideally and not hosting multiple roles on one server.

[ibpalle]

Best practise is really down to context in this case. If there is an already existing NPS install used for RADIUS auth, then keep using that - RADIUS accounting can then either be sent to the Smoothwall and forwarded from there to the NPS or the other way around. Forwarding on the Smoothwall is a bit easier to configure.

 

If there's no existing RADIUS server, then use Smoothwall for both auth and accounting.

 

Edit: BTW, the reason DHCP is sometimes in the mix is when there is no 'Framed-IP' attribute presented to the Smoothwall in the accounting packets. Smoothwall relies on that information to get the IP of the user to login. If it's not there, it can sometimes work if the Smoothwall is the DHCP server for the network as we can look at DHCP leases to find the MAC address and IP of the newly logged in user.

Edited May 14, 2021 by ibpalle

[Primus]

It also depends how you segment your network - for example we use NPS and forward accounting for trusted devices but for untrusted devices they're isolated entirely so use the Smoothwall for authentication and accounting.

[simpsonj]

I think you might be better off having NPS on its own VM ideally and not hosting multiple roles on one server.

 

"To optimize NPS authentication and authorization response times and minimize network traffic, install NPS on a domain controller."

 

From Network Policy Server Best Practice

 

But, as ever, each network has it's own needs!

 

Ultimately, using the Smoothwall for authentication didn't work for me, so moving it to either a DC or another server may work for someone else.

[Primus]

"To optimize NPS authentication and authorization response times and minimize network traffic, install NPS on a domain controller."

 

From Network Policy Server Best Practice

 

But, as ever, each network has it's own needs!

 

Ultimately, using the Smoothwall for authentication didn't work for me, so moving it to either a DC or another server may work for someone else.

 

I know they say that but we keep our servers as single role as possible.

[foofighterjim]

So will a fix for this be forthcoming or is this something I'm going to have to contact support about? It doesn't exactly seem like an isolated problem and I don't fancy remembering to reapply the fix after each update.

[sonofsanta]

Getting rid of the mac1x chain will prevent this from happening - possibly the new features on iOS and Android with dynamic MAC addresses is causing problems as well when paired with the mac1x functionality.

 

Ah that would make sense, as I believe the issue started appearing around the time OS 14 came out.

 

 

So what I'm hearing is I can blame Apple for all this? Suits me

[ibpalle]

We are likely addressing this in the Maiden update. Discussions are going on at the moment. Could possibly be done sooner - I'm pushing for it at least.

[sonofsanta]

Yes, that sounds like the same kind of issue - When you've got a device that's presenting with it, try loading a website (It'll hang) and run the

iptables -F mac1x

 

 

command via SSH - It should instantly start responding again. If it does, then yes it's the same issue.

 

 

Just had this pop up again for the first time since starting the thread, and this one-line, seventeen-character command fixed something that's been winding me up for 6 months because the Smoothwall support tech couldn't tell me what was happening when I logged it. asdkjhafkjhagafhkjashfaf and also omgthankyou

[tom_newton]

The annoying non-feature which is causing this should be removed in Leeds-54.

[DrCheese]

The annoying non-feature which is causing this should be removed in Leeds-54.

 

When's this out? (Be nice not to have to keep adding the workaround on both machines after patching)

[DrCheese]

Hi there -

 

We've got Leeds 54 appearing now on our update list but I cant see this mentioned in the release notes - Did this make it into it?

[sjatkn]

Yes, that sounds like the same kind of issue - When you've got a device that's presenting with it, try loading a website (It'll hang) and run the

iptables -F mac1x

 

 

command via SSH - It should instantly start responding again. If it does, then yes it's the same issue.

 

Thanks for this. It's been happening to us for a couple of years now, but quite intermittently. We kept our old Smoothwall as a failover spare, so whenever it happened I switched to the failover, rebooted the primary and then failed back. It worked but was not ideal. I've just tried this today and it did indeed seem to fix the problem.

 

The only issue I have now is that I have Leeds-54 on the old S12 but it's not showing up for the new S10. I've got a case open with Smoothwall so I hope they will sort it soon.

Edited December 6, 2021 by sjatkn

[ibpalle]

Here is a script we sometimes place on systems to make sure the mac1x chain gets removed - normal warnings to apply here with regards to accessing console and running scripts so ...

 

Add a file called /etc/actions/secondboot/9999deletemac1x

 

Edit and add this to the file:

 

#!/bin/bash

#This script deletes the mac1x chain from iptables to resolve MAC to IP address Binding issue with BYOD/RADIUS setups

#Note: This DELETES the chain it DOES NOT flush the chain

 

/sbin/iptables -F mac1x

/sbin/iptables -D INPUT 1

/sbin/iptables -D FORWARD 1

/sbin/iptables -F mac1x

/sbin/iptables -X mac1x

 

Save and chmod +x the file. Reboot or clear the mac1x and run this script

[DrCheese]

Super old thread, but is this bug perm fixed in Maiden now? (Just to save my fingers after each update!)

[tom_newton]

Er, hmmm... I will find out - nothing jumps out at me that says "yes"

[tom_newton]

Not yet is the answer - a future maiden release, though your fix should be upgrade-proof

[DrCheese]

Ah thanks - Yes, have found it's hit/miss if we have to comment out the fix after each reboot. Will keep checking for now just in case!