On Monday, September 08, 2014 at 12:07 AM, "Michael Rash" wrote:
On Sun, Sep 7, 2014 at 11:02 PM, 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
Hi Mike, Thanks for the quick reply - the project box would be the
default gateway for a given deployment and is running dhcpd to issue
ip addresses to connecting clients. I'm not super familar with the NAT
capabilites of fwknop but as long as I could designate which interface
the NAT was to occur on (i.e. tun0 vs. eth0, etc.) then option 1 would
probably work just fine and the "timing out" is desirable....looking
for this to work on the LAN side in a manner similar to how it would
work for remote access. Thanks again...
------------------------------------------------------------------------------
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
