[Openswan Users] Problems with RDP over IpSec

[John Riley]

Preface:  I really don't think this is an OpenSwan problem, but we are 
somewhat at a stand.  I have virtually nothing to do with the Windows 
side of things (I set up the Linux gateway only).

We have a net configuration that uses an OpenSwan gateway in the home 
office and Win XP 'roadwarriors' in the branch office.  On the home 
office (Site A) net is a Win2003 file/application server running the 
office management software and holding the database.

192.168.1.0 --- 192.168.1.100/a.b.c.d -{ Internet }- 
w.x.y.z/192.168.2.100 --- 192.168.2.0
                            Linux/OpenSwan                             
cheapie D-Link router


The Win2003 box is at 192.168.1.50.

The remote (Site B) clients use RDP to connect to the Win2003 box and 
run the office app.  The system was working properly until the end of 
February.  Since that time, the remote office XP clients cannot RDP to 
the Win2003 box.  Here are some tests we've done.

(1) With the tunnel up, Win XP client computers on the 192.168.2.0 net 
can ping any host on 192.168.1.0, including 192.168.1.50.

(2) With the tunnel up, Win XP client computers on the 192.168.2.0 net 
can use Network Neighborhood (or whatever) to browse shares on any host 
on 192.168.1.0, including 192.168.1.50.

(3) With the tunnel up, Win XP client computers on the 192.168.2.0 net 
can use TightVNC to connect to a single desktop on 192.168.1.50.

(4) Using a Linux client running OpenSwan on 192.168.0.0 at a different 
remote site (Site C), I can connect RDP to 192.168.1.50.

(5) Taking one of the remote office computers from the remote office to 
another site (Site D), setting up that net to be 192.168.2.0, the XP 
client CAN connect RDP to 192.168.1.50.  The router used at Site D was 
taken to Site B and using the same XP client, failed to connect RDP to 
192.168.1.50.

(6) Any XP client on 192.168.1.0 can RDP into 192.168.1.50.

(7) With the tunnel up, Win XP client computers on the 192.168.2.0 net 
can RDP into Win XP clients on the 192.168.1.0 net.

(8) Any client (Site B, C, or D) can ssh into the gateway over the tunnel.

Iptables on the gateway is set up to allow input and forward for all 
packets arriving via the tunnel.  (I'm using a 2.6 kernel with netkey, 
the packets are marked as they come in, and any marked packet gets 
forwarded).  All packets, except 'established connections,' that are not 
marked are logged and dropped.

All tests suggest to me that the VPN tunnel is working properly.  To me, 
these tests suggest that the problem is something on the 2003 box, 
EXCEPT 4,5,6,7.

However, we put ethereal on the Win2003 box and captured some packets.  
On a failed attempt to connect, we get
packets listed as

[TCP Previous Segment Lost] 3532 > 3389 [PSH, ACK] Seq=7977 Ack=1694 
Win=65288 Len 498

and the next packet being marked [TCP Dupe ACK 31#1]

with none of these showing up the RDP connections via the tunnel that 
succeed.

Nothing is being written to the logs on the OpenSwan gateway, and 
nothing is being written to the logs on the Win2003 box.  (I asked them 
to enable Oakley logs on the XP clients; if they did, they have not 
reported to me if anything is showing up there).

So, I guess what I really want from this list is independent 
confirmation that the issue is NOT with OpenSwan or that it might 
actually be.

Also, I have been repeatedly asked if the issue "might be" the DSL 
modem/ISP equipment on the Remote office side.  The points I keep making 
to this are

(1) via the tunnel, the routers/equipment between remote office client 
and OpenSwan gateway does not know anything about packet destinations or 
tunneled protocols.  In other words, Bellsouths routers don't know a 
tunneled RDP packet for 192.168.1.50 from an ICMP Echo request for 
192.168.1.50 from a RDP packet for 192.168.1.7.  If things work for one 
type of traffic to the internal net, they should work for ALL types, 
right?  (As far as DSL modem/ISP equipment is concerned at least).  All 
that equipment sees is UDP packets destined for a.b.c.d on the NAT-T port.

and

(2) 192.168.1.50 does not see anything except a packet from 192.168.2.4; 
it does not 'know' the packet has been routed over the net.


Any thoughts or input regarding possible solutions or even additional 
tests would be greatly appreciated.

-- 
John S. Riley, Ph.D.
DSB Scientific Consulting
http://www.dsbscience.com