[vpn-help] Asymmetric routing between Shrewsoft 2.1.7 and OpenSwan

[Erich Titl]

Hi Folks

I am trying to connect a road warrior on Windows 7 Home and a dated
OpenSwan 2.4.7 installation, using X.509 certs.

At first the connection apears to come up fine as reported by the
Shrewsoft client and also by the log from OpenSwan

Aug 25 09:05:11 gatekeeper-internal pluto[1356]: "mega"[2] 192.168.1.186
#6007066: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Aug 25 09:05:11 gatekeeper-internal pluto[1356]: "mega"[2] 192.168.1.186
#6007066: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed,
expecting QI2
Aug 25 09:05:11 gatekeeper-internal pluto[1356]: "mega"[2] 192.168.1.186
#6007066: Dead Peer Detection (RFC 3706): enabled
Aug 25 09:05:11 gatekeeper-internal pluto[1356]: "mega"[2] 192.168.1.186
#6007066: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Aug 25 09:05:11 gatekeeper-internal pluto[1356]: "mega"[2] 192.168.1.186
#6007066: STATE_QUICK_R2: IPsec SA established {ESP=>0x9c4722a6
<0x7190e0e6 xfrm=AES_256-HMAC_SHA1 NATD=none DPD=enabled}

However, when I try to send an icmp echo request to the remote network I
see the packet coming from the configured virtual address, but
travelling in the clear, not in the tunnel. The reply though is sent
through the tunnel.

This is the data coming in on the clear on vlanxx on the OpenSwan gateway.

09:20:42.176576 IP 172.22.53.10 > 172.29.4.1: ICMP echo request, id 1,
seq 486, length 40

This is the data I see on the internal intgerface

09:20:42.176654 IP 172.22.53.10 > 172.29.4.1: ICMP echo request, id 1,
seq 486, length 40
09:20:42.177925 IP 172.29.4.1 > 172.22.53.10: ICMP echo reply, id 1, seq
486, length 40

This is what I see in the tunnel interface ipsec0 on the OpenSwan gateway.

09:20:42.177935 IP 172.29.4.1 > 172.22.53.10: ICMP echo reply, id 1, seq
486, length 40

Here are the exported settings on the client.

n:version:2
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:0
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:0
n:network-notify-enable:1
n:client-wins-used:0
n:client-wins-auto:0
n:client-dns-used:1
n:client-dns-auto:0
n:client-splitdns-used:0
n:client-splitdns-auto:0
n:phase1-dhgroup:2
n:phase1-keylen:0
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:0
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
s:network-host:xxx.yyy.zz
s:client-auto-mode:disabled
s:client-iface:virtual
s:client-ip-addr:172.22.53.10
s:client-ip-mask:255.255.255.255
s:network-natt-mode:enable
s:network-frag-mode:disable
s:client-dns-addr:192.168.1.1
s:client-dns-suffix:ruf.ch
s:auth-method:mutual-rsa
s:ident-client-type:asn1dn
s:ident-server-type:asn1dn
s:phase1-exchange:main
s:phase1-cipher:auto
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
n:phase2-pfsgroup:2
s:policy-level:auto
s:policy-list-include:172.29.0.0 / 255.255.0.0
s:auth-client-cert:xyz.crt
b:auth-client-cert-data:xxxxxxxxxxxx
b:auth-client-key-data:yyyyyyyyyyyyy
b:auth-server-cert-data:zzzzzzzzzzzzzz

Any ideas?

Thanks

Erich Titl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2182 bytes
Desc: S/MIME Kryptografische Unterschrift
URL: <http://lists.shrew.net/pipermail/vpn-help/attachments/20110825/da8888b6/attachment.bin>