[Openswan Users] Stuck on a NATTy X problem

[Barry Reinhold]

I'm a bit lost in the isolation of this problem, guidance would be
appreciated:

The Issue:
When using an ipsec VPN between a Windows XP gateway (as a client) and
an openswan gateway (as a server), an applications server behind the
openswan gateway can not create an X display on the XP box, but it can
ping it.

Network Layout:

Simple form:
[ipsec client] -- NAT -- Internet -- NAT/ipsec server -- [application
server]

More detailed form:
<Windows XP ipsec Gateway(client & X display) @ 192.168.130.195>
connects to:
<eth0 192.168.130.254 NAT DHCP-serverd-address eth1> connects to:
public internet connects to:
<eth1 static public IP NAT/openswan ipsec Gateway(server) @
192.168.127.0/24> connects to:
<linux server where X applications are being run (192.168.127.252)>

Problem Description:
Once an ipsec SA is established between the ipsec client on the XP box
and the combined NAT/ipsec server, a ping can be performed from the
application server (192.168.127.252) to the ipsec client
(192.168.130.195). On the network this travels via a UDP encapsulated
ESP message, with the destination IP address being the NAT box.
When an xterm is created (xterm -display 192.168.130.195:0.0) no display
is created on the XP box. The first two packets (going to the XP box
from the openswan gateway) use a particular SPI and are UDP encapsulated
ESP packets traveling to port 4500. The returning packets use a
different SPI and travel ESP encapsulated (do not go through UDP and
port 4500). The box running openswan then sends out a packet to
destination port 6000 (X)(source port 4500) but to IP address
192.168.130.195 -- which, of course, dies with an ICMP Destination
unreachable.

I can ping the XP client from the applications server both before and
after the X failure.

In the openswan log I see this message:

Feb  8 15:29:00 eiger pluto[20134]: ERROR: asynchronous network error
report on eth1 for message to 192.168.130.195 port 6000, complainant
64.222.186.1: Network is unreachable [errno 101, origin ICMP type 3 code
0 (not authenticated)]

Any ideas on how to take the next step in isolating this?


Couple of technical questions:

1. Should the ESP packet's SPI be the same for the  "echo request" and
"echo reply" associated with a ping from a given system.
2. If a ping is initiated in the other direction would there be a
different SPI? (i.e. I have associated an SPI with a given "tunnel"
between two ipsec peers and I'm surprised that they are different --
does this indicate a problem?)

I can provide /etc/ipsec.conf, /etc/iptables -L -v, openswan log files,
and ethereal trace files if helpful.

Barry Reinhold
Lamprey Networks
bbr at lampreynetworks.com
(603) 868-8411