On Thu, Jun 4, 2015 at 12:12 PM, Jonathan Bennett <[email protected]>
wrote:

> Looking at the cli client implementation and man pages, it seems that
> sending a server command requires a source ip address. If there is no port
> opened, is the source address used for anything?
>

The source address isn't used for anything - just a placeholder of 0.0.0.0
will work (-s on the client command line) unless on the server side you
require a specific IP with the SOURCE keyword, or you set
REQUIRE_SOURCE_ADDRESS.


> I have server command and nat access working from fwknop2, and thinking
> about the ui. When server command mode is used, I would like to disable
> also opening a port, and just set the source ip to 0.0.0.0. Is there a
> downside to this that I'm overlooking?
>
That will work just fine.

Thanks,

--Mike



> ~Jonathan Bennett
>
> On Thu, Jun 4, 2015, 8:11 AM Michael Rash <[email protected]> wrote:
>
>> On Wed, Jun 3, 2015 at 1:17 PM, Jonathan Bennett <[email protected]>
>> wrote:
>>
>>> Looking at nat-access, it seems that the internal destination must be an
>>> ip address. Is this correct?
>>>
>>
>> Yes, that is correct. The only DNS resolution (outside of -R external IP
>> lookups) done currently is by the client for the main SPA destination if it
>> is a hostname instead of an IP.
>>
>>> If so, it would be useful to support resolving a dns name instead of
>>> only allowing an ip. Use case being a local network that runs dhcp.
>>> Individual devices can be assigned different ip addresses, but if dns is
>>> set up correctly, it should always resolve to the correct machine.
>>>
>>
>> Agreed this would be nice. There are a couple of ways this could be
>> implemented. Probably the easiest would be to extend the server-side
>> FORCE_NAT variables in the access.conf file to allow hostnames. This would
>> mean that libfko would not need to be changed, but the downside would be
>> that the client could not specify the desired hostname up front. A more
>> complete solution would be to extend libfko itself. This would allow the
>> server to receive the hostname via an SPA packet, and then the server can
>> do the resolution which is likely a requirement to make this feature really
>> work to account for internal vs. external DNS mappings.
>>
>> I think we can do both of the above starting with extending the FORCE_NAT
>> stuff in one of the next releases. I'll add the libfko change as well, but
>> probably for the 3.0 release which will also introduce some other libfko
>> changes.
>>
>> Thanks,
>>
>> --Mike
>>
>>
>>> ~Jonathan Bennett
>>>
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Fwknop-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
>>
>


-- 
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F
------------------------------------------------------------------------------
_______________________________________________
Fwknop-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss

Reply via email to