freebsd security - May 2013 - PF + gif + ipsec + racoon + routing problems results in insecure ipsec vpn

Hi everyone,

I wrote up a post on the FreeBSD forums about the issue I am having.  It's
rather long so I am providing a link to it here:
http://forums.freebsd.org/showthread.php?t=39595

In summary, it seems that when the packets are routed in to the gateway from
local network hosts, the src and dst addresses are changed to the public IPs of
the tunnel -- at least from the perspective of the ipsec stack. This is breaking
the ESP encryption in certain cases.  I found a workaround, but it is not what
is documented in the handbook.

In short, if you setup a vpn per the FreeBSD Handbook article that I mention in
my post, you are left with a most-insecure vpn which you believe is secure. 
Traffic is only secure *between* the two gateways, but *not* between hosts
behind those gateways (i.e. private hosts at either site).

(I apologize in advance if I'm breaking a mailing list rule by pointing you
all to the forum URL -- I'm somewhat new to the list).

Thanks,
Daniel

Daniel Duerr <dd at ouido.net> wrote:
>
> Hi everyone,
> 
> I wrote up a post on the FreeBSD forums about the issue I am
> having.  It's rather long so I am providing a link to it here:
> http://forums.freebsd.org/showthread.php?t=39595
> 
> In summary, it seems that when the packets are routed in to the
> gateway from local network hosts, the src and dst addresses are
> changed to the public IPs of the tunnel -- at least from the
> perspective of the ipsec stack. This is breaking the ESP encryption in
> certain cases.  I found a workaround, but it is not what is documented
> in the handbook.
> 
> In short, if you setup a vpn per the FreeBSD Handbook article that I
> mention in my post, you are left with a most-insecure vpn which you
> believe is secure.  Traffic is only secure *between* the two gateways,
> but *not* between hosts behind those gateways (i.e. private hosts at
> either site).
> 
> (I apologize in advance if I'm breaking a mailing list rule by
> pointing you all to the forum URL -- I'm somewhat new to the list).
> 
> Thanks,
> Daniel

I believe your problem may stem from the SPD policy you're using, for
example:

    flush;
    spdflush;
    spdadd 1.1.1.0/24 2.2.2.0/24 any -P out ipsec
esp/tunnel/A.A.A.A-B.B.B.B/use;
    spdadd 2.2.2.0/24 1.1.1.0/24 any -P in ipsec esp/tunnel/B.B.B.B-A.A.A.A/use;

Specifically, the level keyword "use" in the policy specifier.  The
man
page says:

    The 'level' is one of the following:  default, use, require or
    unique.  [...]  A value of 'use' means that the kernel will use
    an SA if it is available, otherwise the kernel will pass the packet
    as it would normally.

I suggest you test again, using the keyword 'require' instead of
'use',
to see if it forces the kernel to generate SA's in both directions,
rather than just one direction.


P.S.  I've never quite understood why the Handbook recommends GIF
    tunneling be used, when ESP tunnel mode already provides the
    ability to encapsulate packets natively.  It seems to me that an
    administrator should either use GIF + IPSEC Transport mode, or IPSEC
    Tunnel mode without GIF, for simplicity.

-- 
David DeSimone == Network Admin == fox at verio.net
  "I don't like spinach, and I'm glad I don't, because if I
   liked it I'd eat it, and I just hate it." -- Clarence Darrow


This email message is intended for the use of the person to whom it has been
sent, and may contain information that is confidential or legally protected. If
you are not the intended recipient or have received this message in error, you
are not authorized to copy, distribute, or otherwise use this message or its
attachments. Please notify the sender immediately by return e-mail and
permanently delete this message and any attachments. Verio Inc. makes no
warranty that this email is error or virus free.  Thank you.