[Openswan Users] Problems with RDP over IpSec

[Gary W. Smith]

My guess is MTU.

Try pining with a 10k packet to another node on the otherside (not the
firewall itself) - (ping -l 10000 10.0.32.6).  It'll probably drop as
well.  I'll take a guess that one of your lines is some type of DSL.

We have a couple nodes that are on very slow links and found that the
VPN was unreliable at best.  We had already tweaked down the MTU to
compensate to find out that one of the particular ISP's also had another
device which chewed up another 64 bytes, requiring us to drop it down to
like 1400 in order to make the tunnel work properly.

Hope that helps.

> -----Original Message-----
> From: users-bounces at openswan.org [mailto:users-bounces at openswan.org]
On
> Behalf Of John Riley
> Sent: Wednesday, April 05, 2006 2:01 PM
> To: users at openswan.org
> Subject: [Openswan Users] Problems with RDP over IpSec
> 
> 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
> 
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
>
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155