On Mon, Sep 8, 2014 at 10:50 AM, <[email protected]> wrote:
>
>
> On Monday, September 08, 2014 at 12:07 AM, "Michael Rash" <
> [email protected]> wrote:
>
>
> 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
>
> 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.
>
>
>
Hi,
After looking at this a bit closer, fwknop is not a great fit as it stands
currently, but I've opened a new issue on github to support your use case:
https://github.com/mrash/fwknop/issues/131
Basically the problem is the fwknopd currently requires DNAT rules whenever
any SNAT (or MASQUERADE) rules are added. While this does allow fwknopd to
support NAT'd communications, the DNAT requirement means that NAT
operations are only applied to IP packets that clients send directly to an
IP that is bound to the gateway device - not IP packets that are sent
_through_ the gateway. So, even though the use case would be supported for
individual outbound connections to external services (so a client would,
say, ssh to the gateway IP and would transparently be connecting to some
ssh server out on the Internet somewhere), this doesn't work for the vast
majority of client communications. Normal web browsing would not work for
example since the destination IP handed to each client is derived from
external DNS, and the client sends packets to web server IP's directly via
the gateway.
What is needed is for fwknop to support MASQUERADE rules without
corresponding DNAT rules. I'm hoping to get this into the next release.
Thanks,
--Mike
>
> 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
