[Openswan Users] help request - traffic not going through IPsec tunnel

[David Forbis]

Hi - I'm hoping someone can give me a hint toward solving a
problem that's had me stuck for quite some time.  In a nutshell,
it seems that traffic destined for the VPN zone are not entering
the IPsec tunnel.

Setup:
Redhat 9.0, updated to running kernel version 2.6.5
Openswan version 2.1.1 (OE disabled)
Shorewall version 2.0.1
The user (me) is pretty much ignorant to routing and ipsec, knowing
only what I've read and actually understood.

Symptoms:
The tunnel appears to be established at both ends.  ping and traceroute
from the local side don't enter the tunnel, they attempt to route as if
they were default traffic.  On the remote side, it appears that ping
and traceroute attempt to use the tunnel, but they get no reply, nor
do they show up on the local side during a tcpdump.

I'm a bit confused as to some conflicting messages.  On both the local
and remote ends, the tunnel appears to be established as reported
by ipsec auto --status, however in my local /var/log/messages, I
get a "could not start conn" error.  Is the tunnel actually there and
the messages error bogus, or is this symptomatic of my problem?

When I start ipsec, I get an additional entry in my routing table
describing the new route, bound to interface eth0, as expected.
Interestingly enough, if the address space of my LAN overlaps the
address space defined by the VPN, my LAN is no longer routable,
despite the fact that it still shows up first on the routing
table (bound to eth1).  I "fixed" this my changing the routing
space of the VPN connection.  However, this makes me suspicious
that something fundamental is wrong with my routing.

I'm pretty sure this isn't a shorewall problem.  I've got my
configuration put together as documented at:
http://lists.shorewall.net/pipermail/shorewall-users/2003-December/010417.html
Also, the same behavior is shown when shorewall is set to "clear",
which I understand to be wide open.

Is there something fundamental that I'm missing?  Is there anything
other than the userspace tools that tell the kernel what needs to be
encrypted and routed through the tunnel?

For privacy's sake, I've removed some of the ip addresses in the
reports below.  I hope that didn't confuse everything.  "x.x.x.x" denotes
a remote address, "y.y.y.y" denotes a local address.  For brevity's sake,
I did not attach an ipsec barf, but one may be found at:
http://www.forbis.org/ipsecbarf.txt

I hope I've provided enough information - I've been working on this
problem on and off for weeks now, and have run out of things to try.
Any suggestions would be graciously accepted.

Thanks and regards,
Dave


# traceroute (remote machine, inside VPN space)
traceroute to hai10 (10.90.101.70), 30 hops max, 38 byte packets
 1  10.32.64.1 (10.32.64.1)  97.982 ms  103.705 ms  90.462 ms
 2  srp4-0.austtxa-rtr1.austin.rr.com (66.68.2.254)  136.394 ms  71.091 ms
27.545 ms
 3  srp0-0.austtxrdc-rtr2.austin.rr.com (66.68.1.253)  36.145 ms  17.694 ms
28.042 ms
 4  pos6-0.austtxrdc-rtr4.texas.rr.com (66.68.1.106)  7.459 ms !H
^c


# tail /var/log/messages
Apr 10 12:25:07 mars ipsec_setup: Starting Openswan IPsec U2.1.1/K2.6.5...
Apr 10 12:25:08 mars ipsec_setup: KLIPS ipsec0 on eth0
y.y.y.y/255.255.240.0 broadcast 255.255.255.255
Apr 10 12:25:08 mars ipsec_setup: ...Openswan IPsec started
Apr 10 12:25:08 mars ipsec__plutorun: 104 "dforbis-vpn1" #1:
STATE_MAIN_I1: initiate
Apr 10 12:25:08 mars ipsec__plutorun: ...could not start conn "dforbis-vpn1"


# ipsec auto --status
000 interface eth0/eth0 y.y.y.y
000 interface lo/lo 127.0.0.1
000 interface eth1/eth1 10.90.105.153
000 %myid = (none)
000 debug none
000 000 "dforbis-vpn1":
10.90.105.152/29===y.y.y.y[@dforbis]---66.25.128.1...x.x.x.x---x.x.x.x===10.90.101.0/24;
erouted; eroute owner: #2
000 "dforbis-vpn1":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
000 "dforbis-vpn1":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP; prio: 29,24;
interface: eth0;
000 "dforbis-vpn1":   newest ISAKMP SA: #1; newest IPsec SA: #2;
000 000 #2: "dforbis-vpn1" STATE_QUICK_I2 (sent QI2, IPsec SA
established); EVENT_SA_REPLACE in 28090s; newest IPSEC; eroute owner
000 #2: "dforbis-vpn1" esp.74c2132a at x.x.x.x esp.3ef45f69 at y.y.y.y
tun.0 at 65.90.9.114 tun.0 at 66.25.129.74
000 #1: "dforbis-vpn1" STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 2847s; newest ISAKMP
000


# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                         [OK]
Linux FreeS/WAN U2.1.1/K2.6.5 (native) (native)
Checking for IPsec support in kernel                                    [OK]
Checking for RSA private key (/etc/ipsec.secrets)                       [OK]
Checking that pluto is running                                          [OK]
Two or more interfaces found, checking IP forwarding                    [OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command                                               [OK]
Checking for 'iptables' command                                         [OK]
Checking for 'setkey' command for native IPsec stack support            [OK]

Opportunistic Encryption DNS checks:
   Looking for TXT in forward dns zone: mars
[MISSING]
   Does the machine have at least one non-private address?              [OK]
   Looking for TXT in reverse dns zone: 74.129.25.66.in-addr.arpa.
[MISSING]