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:
> 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.
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.
>> Will D. Spann