[Openswan Users] Packets not going through tunnel
T. Russell Budd
buddtr at HBCS.Org
Thu May 27 11:12:39 CEST 2004
Hi,
I'm attempting to establish a Windows XP to Openswan 2.1.2
connection.
The PC is up to date and has the latest NAT-T patch (although I'm
not yet using NAT).
I'm running RH9, Openswan 2.1.2, and L2TPD 0.69. I have followed
Jacco's instructions and it appears that I can establish an IPSEC
connection. At the moment I am trying this with PSK and a fixed IP
for the PC.
I am unable to get the l2tp connection started. Sniffer output shows
that the l2tp response packets from the RH9 machine to the PC are
not being encrypted and thus ignored by the PC client. Eventually
l2tp times out and the ipsec tunnel is torn down.
I'm sure I've just missed something, but does anyone have an idea
what?
I've included some snippets of logs. It looks like the tunnel is stuck
in 'hold'.
Thanks
Russ
==================================================
# /etc/ipsec.conf - FreeS/WAN IPsec configuration
file
# RCSID $Id: ipsec.conf.in,v 1.12 2004/01/20
19:37:13 sam Exp $
# This file:
/usr/local/share/doc/freeswan/ipsec.conf-sample
#
# Manual: ipsec.conf.5
#
# Help:
# http://www.freeswan.org/freeswan_trees/freeswan-
2.1.2/doc/quickstart.html
# http://www.freeswan.org/freeswan_trees/freeswan-
2.1.2/doc/config.html
# http://www.freeswan.org/freeswan_trees/freeswan-
2.1.2/doc/adv_config.html
#
# Policy groups are enabled by default. See:
# http://www.freeswan.org/freeswan_trees/freeswan-
2.1.2/doc/policygroups.html
#
# Examples:
# http://www.freeswan.org/freeswan_trees/freeswan-
2.1.2/doc/examples
version 2.0 # conforms to second version of
ipsec.conf specification
# basic configuration
config setup
interfaces="ipsec0=eth1"
nat_traversal=yes
# Debug-logging controls: "none" for
(almost) none, "all" for lots.
# klipsdebug=all
plutodebug=all
# Add connections here.
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
conn piran-mn
type=tunnel #left is Swan
left=a.b.c.d #the auditors
make me hide addr, sorry
leftprotoport=17/1701
rightprotoport=17/1701 #Right is PC
right=e.f.g.h #
keyexchange=ike #
auth=esp #
authby=secret #
esp=3des-md5-96 #
pfs=no #
keylife=8.0h
rekey=yes
keyingtries=3
compress=no
auto=ignore
==================================================
A snip of Pluto logging that seems to show an
established SA
May 26 13:39:32 piran pluto[1836]: |
install_ipsec_sa() for #398: outbound only
May 26 13:39:32 piran pluto[1836]: | route owner
of "piran-mn" prospective erouted: self; eroute
owner: self
May 26 13:39:32 piran pluto[1836]: | could_route
called for piran-mn (kind=CK_PERMANENT)
May 26 13:39:32 piran pluto[1836]: | sr for #398:
prospective erouted
May 26 13:39:32 piran pluto[1836]: | route owner
of "piran-mn" prospective erouted: self; eroute
owner: self
May 26 13:39:32 piran pluto[1836]: |
eroute_connection replace eroute a.b.c.d/32:0 --
17-> e.f.g.h/32:1701 => esp.3990a
8ab at e.f.g.h (raw_eroute)
May 26 13:39:32 piran pluto[1836]: | executing up-
host: 2>&1 PLUTO_VERSION='1.1' PLUTO_VERB='up-
host' PLUTO_CONNECTION='piran-mn'
PLUTO_NEXT_HOP='204.27.178.18'
PLUTO_INTERFACE='ipsec0' PLUTO_ME='a.b.c.d'
PLUTO_MY_ID='a.b.c.d' PLUTO_MY_CLIENT='a.
b.c.d/32' PLUTO_MY_CLIENT_NET='a.b.c.d'
PLUTO_MY_CLIENT_MASK='255.255.255.255'
PLUTO_MY_PORT='0' PLUTO_MY_PROTOCOL='17'
PLUTO_PEER='e.f.g.h' PLUTO_PEER_ID='e.f.g.h'
PLUTO_PEER_CLIENT='e.f.g.h/32'
PLUTO_PEER_CLIENT_NET='e.f.g.h
' PLUTO_PEER_CLIENT_MASK='255.255.255.255'
PLUTO_PEER_PORT='1701' PLUTO_PEER_PROTOCOL='17'
PLUTO_PEER_CA='' ipsec _updown
May 26 13:39:32 piran pluto[1836]: |
route_and_eroute: firewall_notified: true
May 26 13:39:32 piran pluto[1836]: |
route_and_eroute: instance "piran-mn", setting
eroute_owner {spd=0x80d29d8,sr=0x80d29d8} to #
398 (was #0) (newest_ipsec_sa=#0)
May 26 13:39:32 piran pluto[1836]: "piran-mn"
#398: transition from state STATE_QUICK_R1 to
state STATE_QUICK_R2
May 26 13:39:32 piran pluto[1836]: | inserting
event EVENT_SA_REPLACE, timeout in 3330 seconds
for #398
May 26 13:39:32 piran pluto[1836]: "piran-mn"
#398: IPsec SA established {ESP=>0x3990a8ab
<0xf35e6dbd}
May 26 13:39:32 piran pluto[1836]: | next event
EVENT_SHUNT_SCAN in 39 seconds
May 26 13:40:07 piran pluto[1836]: |
==================================================
Some Klips debugging output that shows a typical
xmit attempt
May 26 13:39:35 piran kernel: klips_debug: IP:
ihl:20 ver:4 tos:0 tlen:40 id:0 DF frag_off:0
ttl:64 proto:17 (UDP) chk:15966 sad
dr:a.b.c.d:1024 daddr:e.f.g.h:1701
May 26 13:39:35 piran kernel:
klips_debug:ipsec_xmit_strip_hard_header:
Original head,tailroom: 2,72
May 26 13:39:35 piran kernel:
klips_debug:ipsec_findroute: a.b.c.d:1024-
>e.f.g.h:1701 17
May 26 13:39:35 piran kernel:
klips_debug:rj_match: * See if we match exactly
as a host destination
May 26 13:39:35 piran kernel:
klips_debug:ipsec_xmit_SAlookup: checking for
local udp/500 IKE packet saddr=cc1bb211,
er=0pc2bf9780
, daddr=cc1bb21e, er_dst=0, proto=17 sport=1701
dport=0
May 26 13:39:35 piran kernel:
klips_debug:ipsec_xmit_SAlookup: shunt SA of
HOLD: skb stored in HOLD.
May 26 13:39:35 piran kernel:
klips_debug:ipsec_tunnel_start_xmit: SAlookup
failed: 2
May 26 13:39:35 piran kernel:
klips_debug:ipsec_tunnel_hard_header: skb-
>dev=ipsec0 dev=ipsec0.
May 26 13:39:35 piran kernel:
klips_debug:ipsec_tunnel_hard_header: Revectored
0p00000000->0pc6ebb2a4 len=127 type=2048
dev=ipsec0
->eth1 dev_addr=00:04:75:a1:7b:1e ip=cc1bb211-
>cc1bb21e
Russell Budd
Hospital Billing and Collection Services
------------------ CONFIDENTIALITY NOTICE ---------------
This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain privileged confidential information
protected by law. Any unauthorized review, use, disclosure or
distribution of this message is prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of this message.
More information about the Users
mailing list