Technical Analysis: Linux VPN & How-To

re: Technical Analysis: Linux VPN & How-To

cybul — Tue, 15 Sep 2009 21:34:59 GMT

re: Technical Analysis: Linux VPN & How-To

cybul — Tue, 15 Sep 2009 21:31:04 GMT

re: Technical Analysis: Linux VPN & How-To

Gl199909 — Tue, 18 Aug 2009 04:50:11 GMT

858585

re: Technical Analysis: Linux VPN & How-To

Gl199909 — Tue, 18 Aug 2009 04:49:54 GMT

ASERDTFYGUHIOOYTRTFYGUHIOK

riverbed wan acceleration

riverbed wan acceleration — Tue, 04 Nov 2008 10:41:20 GMT

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

Windows Vista Beta/Linux IPsec Interop Testing

Port 25 — Thu, 10 May 2007 00:33:58 GMT

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.

OpenVPN deserves mentioning

Rune Kock — Thu, 03 May 2007 13:34:37 GMT

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.

re: Technical Analysis: Linux VPN & How-To

einhverfr — Sat, 10 Mar 2007 23:35:39 GMT

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.