On Sun, Sep 7, 2014 at 11:02 PM, <[email protected]> wrote:
> Hi,
>
>
Hello,
> I have a weird Ubuntu-based project involving mini-ITX computer systems in
> the role of LAN gateways. Each one has multiple bridged network adapters on
> the LAN side plus wireless. One of the requirements is for connection
> security; client systems on the LAN-side connecting to these gateways have
> to be "authorized" before being able to pass traffic.
>
> On the wireless side, I have HostAPD running with 802.1x, EAP-TLS so that
> locks down the WLAN pretty well. However, I have no such functionality
> available for the internal NICs. Even bridged, they are still only a basic
> network adapter and can't provide EAPOL messages to HostAPD. I can do basic
> MAC filtering in IPTables but this is not scalable to any extent and I
> don't really want to delve into a virtual switch/flow controller at this
> point.
>
> I am wondering if it would be possible to use fwknop on the LAN side of
> these gateways for dynamic iptables? Clients not properly configured with
> the correct config, cert, etc. would be blocked from passing traffic. Since
> I pre-provision clients that would operate behind these systems I'd
> configure fwknop to run during startup (or as a service, etc.).
>
> Is this realistic and if so do you have any thoughts, examples, etc. on
> how this might work?
>
>
Interesting use case. Just so I understand, the clients on the LAN have IP
addresses configured/assigned before fwknop could ever be in the picture,
correct? That is, clients can already send IP packets at least to (but
maybe not through) the gateway where fwknopd would be sniffing? If so, then
iptables filtering rules can be applied to client IP addresses instead of
MAC addresses, yes? This almost seems like it would work by using either 1)
the NAT capabilities in fwknopd, or 2) the raw command feature to have
fwknopd implement a NAT rule on behalf of an authenticated client. In both
cases, the iptables policy on the gateway would not forward any packets
from client IP addresses by default. The only way packets would be
forwarded would be after a valid SPA packet is produced by a client. If you
use the NAT capabilities in fwknopd instead of the command feature, then
you would have the benefit of automatically timing out access rules after a
configurable amount of time while established connections could be kept
open through conntrack (just new ones wouldn't be allowed after the timeout
without the client producing another valid SPA packet). In the case of
using the command mode, you would have more flexibility with how you
manually manipulate the iptables policy, but currently there is no "open"
and "close" cycle for this - just execute a command.
If these seem like they might be valid approaches in your environment then
I could provide some configuration guidance so you could try it out.
Thanks,
--Mike
>
> Thanks....
>
>
> The boxes are designed to be "standalone" in that there won't be any
> switches involved
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Fwknop-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
>
--
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F AC69 95D8 5D6B A742 839F
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Fwknop-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
