[strongSwan-dev] Problems with forecast plugin

[Tobias Brunner]

Hi,

> *Issue #1 forecast breaks normal network connectvity*
> 
> On carol, ping dave. Notice ping never reaches dave.
> 
> carol:~# ping -W 1 -c 1 -t 5  10.1.0.130

The reason for this is a policy issue on the server.  The inbound ESP
packet is first tagged with mark 1, then, after decryption, the ICMP
from 10.1.0.129 to 10.1.0.130 gets re-tagged with mark 2 (both via rules
in PREROUTING).

At that point there is a check for a FWD policy for that packet.
However, there is none that matches.  There is one with `src
10.1.0.129/32 dst 10.1.0.0/16` and mark 1 and one with `src
10.1.0.130/32 dst 10.1.0.0/16` and mark 2, but none with mark 2 and
either `src 10.1.0.129/32 dst 10.1.0.0/16` or `src 10.1.0.0/16 dst
10.1.0.130/32`.

While there is a swanctl.conf-option (policies_fwd_out) that causes the
installation of outbound FWD policies (i.e. `src 10.1.0.0/16 dst
10.1.0.130/32` with mark 2 and similarly `src 10.1.0.0/16 dst
10.1.0.129/32` with mark 1) this doesn't actually help.

Because these policies don't have any templates (they are intended to
allow plaintext traffic from the networks behind the gateway in case
there is a default drop policy) the kernel will still reject the packet
due to a template mismatch as the packet will be received via a tunnel
mode SA (the kernel only allows such mismatches for transport mode SAs).

However, even if the policies were installed with templates it still
wouldn't work.  Using this example, the decrypted packet's secpath
contains the inbound SA from carol, which wouldn't match the SA
(addresses and reqid) to dave that would be installed as template with
the matching outbound FWD policy with mark 2.

So this basically doesn't work out-of-the-box and it's not really
specific to the forecast plugin but rather affects forwarding traffic
between tunnels that use unique marks in general (without unique marks
the regular inbound FWD policies match the packets).

Since it's not possible to clear the secpath after re-marking the packet
(or marking the packet after the policy check) it's necessary to install
a FWD policy manually to permit packets between the clients.  For the
example scenario something like this should work:

  ip xfrm policy add src 10.1.0.128/26 dst 10.1.0.128/26 dir fwd \
      priority 200000 tmpl proto esp mode tunnel

No mark is set and the simple template also matches packets from any
client SA (no restriction on IPs and reqid).  The priority is arbitrary
but it must be higher (numerically lower) than that of any FWD policy
that's installed with the CHILD_SAs (their priorities are between 400000
and 268541 in current releases).

> *Isuue #2 forecast injects multiple copies of broadcast message it
> receives.*
> 
> On carol send a broadcast ping with TTL set to 5:
> 
> ...
>
> syslog on moon shows forecast intercepting the packet muttiple times, I
> assume its the packet that it injected is getting intercepted.

Yeah, I guess the packet that's injected here

>  Feb  3 07:13:18 moon charon: 11[NET] forwarding a 10.1.255.255 broadcast from peer 10.1.0.129 to internal network

is probably also received on the AF_PACKET socket and forwarded again.
These sockets are quite special as sent packets bypass Netfilter
completely and received packets are cloned so early that no firewall
rules can be applied either.  So I'm not sure if there is much we can do
about it (it doesn't seem to happen for multicast, though).

Well, I kinda found a hackish way to avoid the duplicates (I guess the
whole plugin is a hack, so...).  Modifying the filter that's attached to
the socket so it only accepts either marked packets (i.e. those received
from the clients) and those from the internal interface, apparently
excludes the packets the plugin injects itself via that socket.  A patch
can be found in the forecast-dups branch.

Regards,
Tobias