Port 25 - Communications from the open source community at Microsoft

Comments RSS

1. einhverfr said:

   Just some supplimental info from my experience that people might find helpful.

   I have build site-to-site Linux vpn appliances before.  I have generally used OpenS/WAN and, optionally, iptools.   Generally, I used pre-shared public/private rsa key pairs (which opens/wan supports w/o X.509).  I am not sure whether the default ipsec-tools supports pre-shared or opportunistic encryption (looking up the public key in a DNS TXT record).

   However, there is one other configuration which can be helpful in a tunnelled environment:  GRE inside of IPSec.  With this protocol, it is possible to forward *any* network traffic whether or not it is TCP/IP based. One can bring a legacy workstation using NetBEUI, SNA, IPX, or even raw ethernet at a remote location into the company network for example.  This configuration however has extra overhead similar to the use of L2TP to encapsulate IPSec.

   I have often seen an assymetric routing problem in VPN setups.  The basic issue is that if you don't have the routing tables set up properly on both sides, it is possible to have reply packets (such as TCP ack's or DNS responses) routed back in the clear across the internet connection.  When this happens, the connecting program will not see the replies and the connections will fail.  This is probably the most common problem with site-to-site setups and is the first thing to check on both sides of the connection.  I would say that it accounts for about 90% of the network problems I have seen on site to site links (the other 10% tends to be dns, address, and key management).  Unfortunately these can be caused by NATs, routers, routing rules, and the like.  If the VPN appliance is not also the main gateway, it can even be difficult or impossible to fix (depending on what the gateway's capabilities are) without upgrading to a better router.

   Finally I wanted to note that in Linux, VPN tunnels are listed as network interfaces.  They show up on ifconfig, and can have routing entries associated with them.  These include IPsec tunnels, GRE tunnels, IPoIP, and the like.  This can also cause a packet to transverse the Netfilter rules multiple times.  For example, a TCP/IP packet coming in via a GRE/IPSec tunnel would transverse first via the IPSec packet coming in from the network interface, then as the GRE packet coming in from the IPSec tunnel interface, then finally as the unencapsulated packet coming from the GRE tunnel interface.

   Anyway, I hope this helps.

   posted at 05:35PM 03/10/2007
2. Rune Kock said:

   IPSec is usually a pain to set up. So if you just need any kind of VPN, I've found that OpenVPN is a lot easier to work with.  It is available for Windows, Linux and many other systems.

   posted at 08:34AM 05/03/2007
3. Port 25 said:

   This document provides an overview of LInux IPsec solutions as well as detailed discussions on configuring IPsec-Tools for interoperability scenarios between Red Hat Linux Enterprise 4 and Windows Vista Ultimate Beta.

   posted at 07:33PM 05/09/2007
4. riverbed wan acceleration said:

   I’ ve had occasion to try out taksi, it worked well for GDI capture, but for Direct3D capture on the engine I used it failed in CTaksiDX9:: GetFrame during GetRenderTargetData. I’ ve found a solution by disabling the avi feature (I didn’ t need it) and

   posted at 04:41AM 11/04/2008