[Openswan Users] Tunnels up, packets from routed machines not going through tunnel

[Paul Goldbaum]

Hi,

we have openswan running on our network's gateway and correctly negotiating
the tunnels. Here's how we are configuring it:
conn csq
        type=tunnel
        left=90.45.241.242 # left is our side
        leftsubnets={90.45.241.242/32,90.45.110.60/32}
        right=33.99.102.36
        rightsubnet=192.168.1.6/32
        authby=secret
        keyexchange=ike
        ikelifetime=24h
        ike=3des-md5;modp1024
        phase2=esp
        phase2alg=3des-md5;modp1024
        salifetime=24h
        auto=add

The gateway has two interfaces(90.45.110.1 and 90.45.241.242) configured to
do IP forwarding and there are no related iptables rules. All IPs on the
network are publicly accessible.

Our problem is that, while we can ping the machine on the other side from
our gateway just fine, the other machine in our subnet(90.45.110.60) is
apparently not being routed through one of the established tunnels but is
instead provoking the negotiation of a new tunnel in it's name. This fails
because on the other side, only the gateway is authorized to be an IKE
peer. What could be wrong in our configuration?

I'm attaching some outputs that might be useful:

This is the output from tcpdump on the gateway's external interface when we
start a ping from our other machine:

09:41:07.444918 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP
(17), length 292)
    90.45.110.60.isakmp > 33.99.102.36.isakmp: [udp sum ok] isakmp 1.0
msgid 00000000 cookie 9ac0140efc0921e3->0000000000000000: phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration
value=7080)(type=enc value=3des)(type=auth value=preshared)(type=hash
value=sha1)(type=group desc value=modp1024))))
    (ke: key len=128)
    (nonce: n len=16
 data=(aff2b8326d0e86135e40...00000014afcad71368a1f1c96b8696fc77570100))
    (id: idtype=IPv4 protoid=udp port=500 len=4 90.45.110.60)
    (vid: len=16)
09:41:07.511314 IP (tos 0x0, ttl 239, id 19841, offset 0, flags [none],
proto UDP (17), length 376)
    33.99.102.36.isakmp > 90.45.110.60.isakmp: [udp sum ok] isakmp 1.0
msgid 00000000 cookie 9ac0140efc0921e3->3c7cc2a83564f6d4: phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=3des)(type=hash
value=sha1)(type=group desc value=modp1024)(type=auth
value=preshared)(type=lifetype value=sec)(type=lifeduration value=7080))))
    (ke: key len=128)
    (nonce: n len=20
 data=(860c9a70bf2268a936be...000000141f07f70eaa6514d3b0fa96542a500100))
    (id: idtype=IPv4 protoid=udp port=0 len=4 33.99.102.36)
    (hash: len=20)
    (vid: len=16)
    (vid: len=8)
    (vid: len=20)
    (vid: len=16)
09:41:07.518286 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP
(17), length 96)
    90.45.110.60.isakmp > 33.99.102.36.isakmp: [udp sum ok] isakmp 1.0
msgid bf1cb318 cookie 9ac0140efc0921e3->3c7cc2a83564f6d4: phase 2/others I
inf[E]: [encrypted hash]

The next packet is again like the first one.

# ip xfrm policy
src 90.45.241.242/32 dst 192.168.1.6/32
 dir out priority 2080 ptype main
tmpl src 90.45.241.242 dst 33.99.102.36
 proto esp reqid 16385 mode tunnel
src 90.45.110.60/32 dst 192.168.1.6/32
 dir out priority 2080 ptype main
tmpl src 90.45.241.242 dst 33.99.102.36
 proto esp reqid 16389 mode tunnel
src 192.168.1.6/32 dst 90.45.241.242/32
 dir fwd priority 2080 ptype main
tmpl src 33.99.102.36 dst 90.45.241.242
 proto esp reqid 16385 mode tunnel
src 192.168.1.6/32 dst 90.45.241.242/32
 dir in priority 2080 ptype main
tmpl src 33.99.102.36 dst 90.45.241.242
proto esp reqid 16385 mode tunnel
src 192.168.1.6/32 dst 90.45.110.60/32
dir fwd priority 2080 ptype main
 tmpl src 33.99.102.36 dst 90.45.241.242
proto esp reqid 16389 mode tunnel
src 192.168.1.6/32 dst 90.45.110.60/32
dir in priority 2080 ptype main
 tmpl src 33.99.102.36 dst 90.45.241.242
proto esp reqid 16389 mode tunnel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openswan.org/pipermail/users/attachments/20120521/a948b103/attachment.html>