Mike,
Thanks for the rapid reply! I'd like to say I'm a big fan of your Linux
Firewalls book. I have learned so much about network security from this book.
Well done.
> On Mar 22, 2013, Will D. Spann wrote: >> I've been trying out the --NAT-local
> functionality with v2.0.3 (on Linux
>> Mint) & v2.0.0-rc1 (on OpenWRT), and I've observed that
>> ENABLE_IPT_FORWARDING
>> must be enabled in fwknopd.conf, otherwise the FWKNOP_PREROUTING chain is
>> not
>> created in the 'nat' table (under iptables). This seems to effectively
>> prevent --NAT-local usage from working at all, as the necessary DNAT rule is
>> not generated.
>>
>> From my reading of the fwknopd documentation, it seems that having
>> ENABLE_IPT_LOCAL_NAT enabled should be sufficient to enable --NAT-local
>> functionality. (I understand that ENABLE_IPT_FORWARDING is required for
>> --NAT-access access to machines behind the firewall running fwknopd.) Am I
>> misunderstanding the meaning of these options, or could this be a bug? I
>> have
>> not yet tested this in v2.0.4, but I didn't find any mention of this problem
>> in the changelog.
> Indeed the ENABLE_IPT_FORWARDING config is required for all NAT
> operations, and here is the relevant code:
> http://www.cipherdyne.org/cgi-bin/gitweb.cgi?p=fwknop.git;a=blob;f=server/incoming_spa.c;h=67929c20a36956fc54391ab0d3b15c25f540e2ae;hb=7bd0da29c42768ca5a8f48a8d1813c12dff363d4#l649
> > The server is written to be restrictive in terms of what clients can
> request, and in this case even though --NAT-local implies that the local
> system running fwknopd is being accessed, the NAT table must be interacted
> with and therefore ENABLE_IPT_FORWARDING must be enabled. It's sort of
> the general gate to determine whether any NAT capabilities are offered to
> valid SPA clients.
Ah, thanks for clarifying. I didn't realize ENABLE_IPT_LOCAL_NAT was dependent
on ENABLE_IPT_FORWARDING. I suppose this makes sense, as you point out that in
both
--NAT-local & --NAT-access usages iptables' 'nat' table needs to be modified to
add the DNAT rule.
> One thing that will be changing in future releases is that more NAT
> capabilities will be integrated with the access.conf file in order to
> offer more granular control on a per access stanza basis.
That would be a terrific feature. It would be nice to be able to allow
--NAT-local access, but disallow NAT forwarding access. Is this currently
possible, on a global basis?
In particular, I'd like to use the ghost service approach (w/ --NAT-port) for
one service (nice blog article btw), and the --NAT-rand-port functionality for
another, where both services are running on the firewall. However, I don't need
to support forwarding to any servers behind the firewall, since I am using a
VPN for that, and would actually prefer to disallow this if possible.
> Thanks, > --Mike
Thanks,
--
Will D. Spann
W. Spann Systems Consulting
P.S., I've recently started following the fwknop project on GitHub. I think the
HMAC functionality you're currently adding will be a great addition. Also, the
support for randomly-generated Rijndael keys will be a nice security
enhancement. I'm looking forward to the v2.5 release. >> Thanks,
>>
>> Will D. Spann
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Fwknop-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
