On Sat, Jul 4, 2015 at 12:02 AM, Michael Rash <[email protected]>
wrote:
>
>
> On Fri, Jul 3, 2015 at 1:02 PM, Kevin Layer <[email protected]> wrote:
>
>> >> I believe that I have this scenario working with the configs
>> >> mentioned below. Note that the 10.211.55.0/24 network is "external"
>> >> to the 192.168.0.0/24 network in my example. Here is what the fwknopd
>> >> log messages look like upon sending an SPA packet with 'fwknop -n B':
>> >>
>> >> # fwknopd -i eth0 -f
>> >> (stanza #1) SPA Packet from IP: 10.211.55.2 received with access
>> >> source match
>> >> [10.211.55.2] (stanza #1) Error creating fko context: Decryption
>> >> failed or decrypted data is invalid
>> >> (stanza #2) SPA Packet from IP: 10.211.55.2 received with access
>> >> source match
>> >> Added FORWARD rule to FWKNOP_FORWARD for 10.211.55.2 -> 192.168.0.5
>> >> tcp/10002, expires at 1435890757
>> >> Added DNAT rule to FWKNOP_PREROUTING for 10.211.55.2 -> 0.0.0.0/0 tcp
>> >> /10002, expires at 1435890757
>> >>
>> >> ... and to see what the rules are themselves:
>> >>
>> >> # fwknopd --fw-list
>> >> Listing rules in fwknopd iptables chains...
>> >>
>> >> Chain FWKNOP_INPUT (1 references)
>> >> num target prot opt source destination
>> >>
>> >> Chain FWKNOP_FORWARD (1 references)
>> >> num target prot opt source destination
>> >> 1 ACCEPT tcp -- 10.211.55.2 192.168.0.5
>> >> tcp dpt:22 /* _exp_1435890757 */
>> >>
>> >> Chain FWKNOP_PREROUTING (1 references)
>> >> num target prot opt source destination
>> >> 1 DNAT tcp -- 10.211.55.2 0.0.0.0/0
>> >> tcp dpt:10002 /* _exp_1435890757 */ to:192.168.0.5:22
>> >>
>> >>
>> >> Here are the configs that make this work. Note that 10.211.55.3 below
>> >> is the IP assigned to the external interface eth0 on the firewall -
>> >> this makes the --nat-local request work for the first stanza. In your
>> >> example, you would replace each instance of this IP with whatever IP
>> >> is on the external interface of your firewall, and this applies to
>> >> both the client and the server:
>> >>
>> >> # cat /etc/fwknop/access.conf
>> >> SOURCE ANY
>> >> OPEN_PORTS tcp/10001
>> >> KEY somekey
>> >> FW_ACCESS_TIMEOUT 60
>> >> FORCE_NAT 10.211.55.3 22
>> >>
>> >> SOURCE ANY
>> >> OPEN_PORTS tcp/10002
>> >> KEY fwknoptest
>> >> FW_ACCESS_TIMEOUT 60
>> >> FORCE_NAT 192.168.0.5 22
>> >>
>> >> # cat /etc/fwknop/fwknopd.conf
>> >> ENABLE_IPT_FORWARDING Y;
>> >>
>> >> $ cat ~/.fwknoprc
>> >> [default]
>> >> ALLOW_IP source
>> >>
>> >> [A]
>> >> SPA_SERVER 10.211.55.3
>> >> KEY somekey
>> >> ACCESS tcp/10001
>> >> NAT_ACCESS 192.168.0.1,22
>> >>
>> >> [B]
>> >> SPA_SERVER 10.211.55.3
>> >> KEY somekey
>> >> ACCESS tcp/10002
>> >>
>> >> On the client command line, you would use:
>> >>
>> >> $ fwknop --nat-local -n A
>> >>
>> >> ... and:
>> >>
>> >> $ fwknop -n B
>> >>
>> >> One minor point about the above as well - the fwknop-2.0.4 client
>> >> isn't able to read the KEY variable from the ~/.fwknoprc file, but
>> >> newer clients can.
>>
>> Thanks, Mike.
>>
>> My testing shows that I can't access both A and B at the same time.
>> After the rules for one are removed, then I can knock and access the
>> other.
>>
>
> Understood - fwknop is working in sequence for both hosts, but not
> simultaneously.
>
>
>>
>> Here I knock consecutively:
>>
>> A then B:
>>
>> fwknopd[22388]: (stanza #1) SPA Packet from IP: SOURCE received with
>> access source match
>> fwknopd[22388]: Added local NAT rule to FWKNOP_INPUT for SOURCE ->
>> 0.0.0.0/0 tcp/10001, expires at 1435942311
>> fwknopd[22388]: Added DNAT rule to FWKNOP_PREROUTING for SOURCE ->
>> 0.0.0.0/0 tcp/10001, expires at 1435942311
>> fwknopd[22388]: (stanza #1) SPA Packet from IP: SOURCE received with
>> access source match
>> fwknopd[22388]: [SOURCE] (stanza #1) One or more requested protocol/ports
>> was denied per access.conf.
>> fwknopd[22388]: (stanza #2) SPA Packet from IP: SOURCE received with
>> access source match
>> fwknopd[22388]: Added FORWARD rule to FWKNOP_FORWARD for SOURCE ->
>> 192.168.0.5 tcp/10002, expires at 1435942315
>>
>> B then A:
>>
>> fwknopd[23448]: (stanza #1) SPA Packet from IP: SOURCE received with
>> access source match
>> fwknopd[23448]: [SOURCE] (stanza #1) One or more requested protocol/ports
>> was denied per access.conf.
>> fwknopd[23448]: (stanza #2) SPA Packet from IP: SOURCE received with
>> access source match
>> fwknopd[23448]: Added FORWARD rule to FWKNOP_FORWARD for SOURCE ->
>> 192.168.0.5 tcp/10002, expires at 1435942367
>> fwknopd[23448]: Added DNAT rule to FWKNOP_PREROUTING for SOURCE ->
>> 0.0.0.0/0 tcp/10002, expires at 1435942367
>> fwknopd[23448]: (stanza #1) SPA Packet from IP: SOURCE received with
>> access source match
>> fwknopd[23448]: Added local NAT rule to FWKNOP_INPUT for SOURCE ->
>> 0.0.0.0/0 tcp/10001, expires at 1435942369
>>
>> Whatever one I knock on first, I can ssh into that host.
>>
>> Maybe in your testing, because the timeout is so low (60), the first
>> rule is removed before you test the second host?
>>
>>
> In the output above, what appears to be happening is that fwknopd is not
> creating the necessary DNAT rule for the second SPA packet. This can happen
> if fwknopd thinks there is already a matching rule in place, but it
> shouldn't be doing that because the ports are different (10001 vs. 10002).
> On your fwknopd server system, can you stop fwknopd, and then restart with
> the following command (you might need to change eth0 to whatever your
> external interface is):
>
> # script -c 'fwknopd -i eth0 -f -v -v -v'
>
> ... then send the SPA packets in A -> B order. Once the rules are removed
> by fwknopd after the timeout, Ctrl-C the fwknopd process, and can you send
> me the resulting 'typescript' file? The information in this file will be
> lengthy, and you'll want to obfuscate your IP addresses, etc. But, this
> should help shed some light on what is going on. I have tried several
> combinations of the 2.6.6 server with the 2.0.4 client (with legacy
> encryption mode turned on), making sure the firewall timeouts are long
> enough to verify that both SSH connections can be opened simultaneously,
> etc. So far, I haven't been able to reproduce this, but we'll get to the
> bottom of it.
>
>
Thanks to Kevin for sending me the output of the above command - I've found
that there is a bug in fwknopd that affects systems with older versions of
iptables. Specifically, for iptables 1.4.7 (and other older releases) where
the '-C' checking functionality isn't implemented, fwknopd does not
properly detect when a rule exists or not in some scenarios. It is
definitely very handy to have the iptables -C feature available, but if it
isn't I'm working on a fix so that fwknopd can properly handle this too.
I'll post a -pre release of fwknop-2.6.7 for testing soon.
Thanks,
--Mike
>
>> Btw, my access.conf, fwknopd.conf and .fwknoprc look like yours, with
>> my values substituted.
>>
>> Kevin
>>
>
>
>
>
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Fwknop-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
