UPDATE: Site-to-Site VPN Using Solaris 9

From: Crist Clark (crist.clark@globalstar.com)
Date: Fri Dec 30 2005 - 16:46:23 EST


I got a few suggestions about this, but none were much of a help. Thanks
anyways. I'm still looking for some help on this. Has no one set up a
Solaris 9/10 IPsec tunnel to some other device? (Note: a TUNNEL. Not
transport mode.)

Here are some things that are NOT the problem or NOT workarounds:

        - The Cisco Concentrator DOES speak plain-ol', standard-compliant
        IPsec. I'm pretty sure of this because I got it to interoperate with
        two other vendors, FreeBSD-racoon and CheckPoint.

        - IKE Phase 1. That all works fine according to the logs at both
        ends. That means the shared-secret keys are OK, for example.

        - I cannot use the Cisco VPN Client for Solaris. See Sun bug #5066781.

        - Trying the "obvious" IPsec policy using ipsecconf(1M) that might
        help doesn't work. See below for the policy.

The problem comes in Phase 2 when the Solaris endpoint is telling
its peer the identities. Here are the logs from both sides. First,
the Solaris end (the initiator which is the sender of this info),

   Fri Dec 30 12:55:39 2005: in.iked: local_i_id = ipv4_subnet(ipip:0,[0..7]=0.0.0.0/0), local_r_id = No Id,
   Fri Dec 30 12:55:39 2005: in.iked: remote_i_id = ipv4_subnet(ipip:0,[0..7]=0.0.0.0/0), remote_r_id = No Id,
   Fri Dec 30 12:55:39 2005: in.iked: Phase 2 error: code 8199 (Aborted notification).

On the Cisco Concentrator end, I see,

   132043 12/30/2005 12:55:54.900 SEV=9 IKEDBG/1 RPT=15 172.19.152.34 Group [172.19.152.34] Processing ID
   132044 12/30/2005 12:55:54.900 SEV=12 IKEDECODE/11 RPT=5 ID_IPV4_ADDR_SUBNET ID received 0.0.0.0 0.0.0.0
   132046 12/30/2005 12:55:54.900 SEV=5 IKE/35 RPT=2 172.19.152.34 Group [172.19.152.34] Received remote IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 4, Port 0
   132048 12/30/2005 12:55:54.900 SEV=9 IKEDBG/1 RPT=16 172.19.152.34 Group [172.19.152.34] Processing ID
   132049 12/30/2005 12:55:54.900 SEV=12 IKEDECODE/11 RPT=6 ID_IPV4_ADDR_SUBNET ID received 0.0.0.0 0.0.0.0
   132051 12/30/2005 12:55:54.900 SEV=5 IKE/34 RPT=440 172.19.152.34 Group [172.19.152.34] Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 4, Port 0
   132053 12/30/2005 12:55:54.900 SEV=8 IKEDBG/83 RPT=2 172.19.152.34 Group [172.19.152.34] QM IsRekeyed old sa not found by addr
   132054 12/30/2005 12:55:54.900 SEV=4 IKE/61 RPT=2 172.19.152.34 Group [172.19.152.34] Tunnel rejected: Policy not found for Src:0.0.0.0, Dst: 0.0.0.0!

How do I tell the Solaris endpoint that this is a tunnel from
172.19.152.34 to 172.19.248.0/24? It's just using 0.0.0.0/0 for both
ends which the other end rejects (as it should). There is nothing I
see in the iked.config(4) or ifconfig(1M) (when the tunnel interface
is set up) manpages that tell me how to set the identities used in
Phase 2. Where and how do I tell in.iked(1M) about the identities for
Phase 2 negotiations?

Here is the IPsec policy that did not work. The system seemed to want to
apply the policy before the packet hit the tunnel. As a result, in.ike(1M)
wants to find a Phase 1 entry for the host I am trying to reach at the
other end of the tunnel rather the endpoint of the tunnel. There is no
such rule, and there shouldn't be, so it dies.

{
         src 172.19.152.34
         dst 172.19.248.0/24
         dir out
} ipsec {
         encr_algs aes
         auth_algs sha1
}

{
         dst 172.19.152.34
         src 172.19.248.0/24
         dir in
} ipsec {
         encr_algs aes
         auth_algs sha1
}

Crist Clark wrote:
> I am trying to set up a site-to-site VPN between a Solaris host and a
> Cisco VPN Concentrator 3000. The desire is for the Solaris endpoint to
> be able to talk to several hosts "behind" the concentrator at the other
> end. I thought setting up a quick IPsec tunnel between these two would
> be a snap, given a little interactive tweaking to get proposals to all
> agree, etc., but Solaris is frustrating me.
>
> I am familiar with implementing VPNs in several other environments,
> and the big problem I'm having with Solaris is how to establish the
> policy. I understand how to set up the ipsecinit file for ipsecconf(1M),
> but that only seems to be used for transport layer IPsec? For a tunnel,
> you need to set up a ip.tun device, see ifconfig(1M), and you specify
> what goes through the tunnel with routing, not with specifying IPsec
> policy. At least that's how I understand things...
>
> So, this problem shows up when the two endpoints start Phase 2 of
> ISAKMP negotiations (yay! I got it to go past Phase 1 successfully!).
> The Solaris endpoint just specifies 0.0.0.0/0 as the network for the
> SA we're trying to set up, and the concentrator end quite correctly
> won't have anything to do with that. It expects to only set up SAs for
> networks it knows about and the Solaris host is allowed to tunnel to.
>
> I haven't been able to find any documents about setting up a IPsec
> tunnel with Solaris 9 to a Cisco VPN Concentrator or for anything else
> but another Solaris system. The one document I did find at Sun's website
> is Solaris-to-Solaris and glosses over all of these problems by having
> the two endpoints pretty much trust each other completely.
>
> Anyone know of any "How Tos" for setting up Solaris 9 IPsec tunnels
> to other OSes? Can anyone offer help with my specfic problem (getting
> Solaris to use the right networks in Phase 2 negotiations)? Note that
> I am deliberately just using vanilla Solaris 9. There's no way I'm
> going to be putting SunScreen on this box. Also, the Cisco VPN Client
> for Solaris won't run on this box due to a known bug, Sun Bug ID 5066781.

-- 
Crist J. Clark                               crist.clark@globalstar.com
Globalstar Communications                                (408) 933-4387
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited.  If you have
received this e-mail in error, please contact postmaster@globalstar.com
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers


This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:38:17 EDT