[Openswan Users] Using Cisco VPN3000
Goffe, Don
Donald.Goffe at GTECH.COM
Fri Oct 2 16:48:13 EDT 2009
I read Paul and Kens' book, great job guys.
I am having an issue when I establish a tunnel thru a Cisco 3000
concentrator.
The tunnel uses netkey and is up. I can ping the concentrator and get an
echo reply just fine. Ethereal confirms the pings have been encrypted in
both directions. My pc is on the left with an address of 150.24.31.22,
the vpn server is 10.10.1.11 and the target Pc is 10.3.15.60 on the
private side of the network.
PROBLEM:
When I ping 10.3.15.60 I see the encrypted echo request get to the
concentrator, be decrypted, and the ICMP ping actually get to the
10.3.15.60 PC. The response is an ICMP echo reply back to 150.24.31.21
as expected, which does not go back over the tunnel and as such is never
encrypted. Instead it simple appears on my terminal as a plain old non
encrypted ICMP reply. The Cisco concentrator indicates my tunnel has an
assigned source address of 255.255.255.255 and a public address of
150.24.31.21. That can't be correct.
Has anyone seen this issue?
Thanks in advance...
Config:
# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.16 2005/07/26 12:29:45 ken Exp $
# This file: /usr/local/share/doc/openswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# Do not set debug options to debug configuration issues!
# plutodebug / klipsdebug = "all", "none" or a combation from
below:
# "raw crypt parsing emitting control klips pfkey natt x509 dpd
private"
# eg:
# plutodebug="control parsing"
#
# enable to get logs per-peer
# plutoopts="--perpeerlog"
#
# Again: only enable plutodebug or klipsdebug when asked by a
developer
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
#nat_traversal=yes
# exclude networks used on server side by adding %v4:!a.b.c.0/24
virtual_private=%v4:10.0.0.0/8
# OE is now off by default. Uncomment and change to on, to
enable.
#oe=off
# which IPsec stack to use. netkey,klips,mast,auto or none
protostack=netkey
# Add connections here
conn gtech
# # Left security gateway, subnet behind it, nexthop
toward right.
type=tunnel
left=150.24.31.22
leftsubnet=150.24.31.0/24
# leftmodecfgclient=yes
leftxauthclient=yes
leftid=@gtech
# # Right security gateway, subnet behind it, nexthop toward
left.
right=10.10.1.11
rightxauthserver=yes
rightsubnet=10.3.15.0/24
rightmodecfgserver=yes
pfs=no
# # To authorize this connection, but not actually start
it,
# # at startup, uncomment this.
# auto=add
auto=route
auth=esp
esp=3des-md5
ike=3des-md5-modp1024
modecfgpull=yes
authby=secret
aggrmode=yes
CONFIDENTIALITY NOTICE: The contents of this email are confidential
and for the exclusive use of the intended recipient. If you receive this
email in error, please delete it from your system immediately and
notify us either by email, telephone or fax. You should not copy,
forward, or otherwise disclose the content of the email.
More information about the Users
mailing list