From owner-freebsd-net@FreeBSD.ORG Sun May 22 08:24:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CD281065673 for ; Sun, 22 May 2011 08:24:02 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 26D958FC14 for ; Sun, 22 May 2011 08:24:01 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 112F8B0380D5 for ; Sun, 22 May 2011 03:58:18 -0400 (EDT) thread-index: AcwYVgDJwLgaoXTMT52NbXT3iWC6dg== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 May 2011 03:58:13 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Sun, 22 May 2011 02:58:12 -0500 Date: Sun, 22 May 2011 02:58:12 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20110522075811.GC3240@verio.net> Content-Class: urn:content-classes:message Importance: normal Priority: normal Mail-Followup-To: freebsd-net@freebsd.org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4841 References: <20110522023056.D08F4106564A@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline In-Reply-To: <20110522023056.D08F4106564A@hub.freebsd.org> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 22 May 2011 07:58:13.0447 (UTC) FILETIME=[00140D70:01CC1856] Subject: Re: IPSec Routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 08:24:02 -0000 jhall@socket.net wrote: > > I am using IPSec in transport mode to connect to a vendor's router. The > connection is established and I am able to see the tunnels are established > in racoon by the IPsec-SA established: ESP/Tunnel messages. And, my > vendor has confirmed the connection is up on their end. Wow, transport mode. I have only set up tunnels in tunnel mode, so I don't have any direct experience to relate, but I can make some educated guesses that might point you in the right direction. > What I am not understanding is how to add routes correctly when > using transport mode. I have added the proper incoming/outgoing > information using setkey. When I display the information using > setkey -DP, the routes appear correct. I have defined one outbound > route for the local private network to the remote private network and > vice versa. What you have set up using setkey is "policy", not "routing." Routing defines WHERE things will go, while policy defines HOW things should go (basically, whether or not the packet should be encapsulated, encrypted, etc.) Since the concepts of policy and routing are separated in FreeBSD, you will probably need to enter the information in a redundant fashion. That is, you will need to enter routes into your route table that will forward traffic towards your vendor. And since you are using transport mode, you'll have to hope that all the intervening routers between you and your vendor will also know to route things in that same direction, and how to route any replies back to you. > When I try to ping the remote network, I do not receive any > responses. Running a traceroute, I see the packet bounced back and > forth between the external interface and the loopback adapter on my > FBSD box. Since you didn't give any configuration information, it's hard to guess why you are seeing that behavior. > This is the first time I have connected two networks together using > transport mode as opposed to tunnel mode and I am really confused as > to what I should be doing. The handbook information seems to deal > only with tunnel mode. Tunnel mode is often preferred because it simplifies routing a great deal. In transport mode, the source and destination IP's are not changed in any way on the encrypted packet, so it is then left as an exercise for your system's route table (and other routers on the Internet) to determine how to route the now-encrypted packet towards a gateway that can decrypt it. This could be as simple as just specifying a route using "route add -net" with a proper gateway, and letting things go from there, or it could get terribly complicated. It all depends on the networking in between. If you were using tunnel mode, the encrypted packet would change its source and destination IP's, specifying your gateway as the source, and your vendor's gateway as the destination, so intervening routers would have no difficulty delivering the packet, or routing reply packets back to you. -- David DeSimone == Network Admin == fox@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.