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


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