[Openswan Users] Problems with RDP over IpSec

Gary W. Smith gary at primeexalia.com
Wed Apr 5 18:13:20 CEST 2006

My guess is MTU.

Try pining with a 10k packet to another node on the otherside (not the
firewall itself) - (ping -l 10000  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]
> 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.
> --- -{ Internet }-
> w.x.y.z/ ---
>                             Linux/OpenSwan
> cheapie D-Link router
> The Win2003 box is at
> 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 net
> can ping any host on, including
> (2) With the tunnel up, Win XP client computers on the net
> can use Network Neighborhood (or whatever) to browse shares on any
> on, including
> (3) With the tunnel up, Win XP client computers on the net
> can use TightVNC to connect to a single desktop on
> (4) Using a Linux client running OpenSwan on at a
> remote site (Site C), I can connect RDP to
> (5) Taking one of the remote office computers from the remote office
> another site (Site D), setting up that net to be, the XP
> client CAN connect RDP to  The router used at Site D was
> taken to Site B and using the same XP client, failed to connect RDP to
> (6) Any XP client on can RDP into
> (7) With the tunnel up, Win XP client computers on the net
> can RDP into Win XP clients on the net.
> (8) Any client (Site B, C, or D) can ssh into the gateway over the
> 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
> marked are logged and dropped.
> All tests suggest to me that the VPN tunnel is working properly.  To
> 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
> 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
> to this are
> (1) via the tunnel, the routers/equipment between remote office client
> and OpenSwan gateway does not know anything about packet destinations
> tunneled protocols.  In other words, Bellsouths routers don't know a
> tunneled RDP packet for from an ICMP Echo request for
> from a RDP packet for  If things work for
> 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).
> that equipment sees is UDP packets destined for a.b.c.d on the NAT-T
> and
> (2) does not see anything except a packet from;
> 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:

More information about the Users mailing list