On September 9, 2014 at 10:17 PM, "Michael Rash" <[email protected]> wrote: > >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 > > >> Ok, I think I understand the issue - I'll keep an eye on the release notes for new versions. 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
