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,

--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

Reply via email to