From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 22EB513827E for ; Tue, 24 Dec 2013 00:04:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C149AE0AC3; Tue, 24 Dec 2013 00:04:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 80D41E0ABD for ; Tue, 24 Dec 2013 00:04:08 +0000 (UTC) Received: from [192.168.1.100] (c-68-49-223-78.hsd1.md.comcast.net [68.49.223.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 8A5AF33F5E7 for ; Tue, 24 Dec 2013 00:04:07 +0000 (UTC) Message-ID: <52B8CF72.1070208@gentoo.org> Date: Mon, 23 Dec 2013 19:04:02 -0500 From: Michael Orlitzky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] VPN question References: <52B830DE.9000706@taydin.org> <52B85D0E.6020001@gentoo.org> <52B85E3C.4000801@taydin.org> <52B860E2.1060307@gentoo.org> <52B8754B.4070005@taydin.org> In-Reply-To: <52B8754B.4070005@taydin.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 9e1efe77-80e3-4c00-a421-93729ddebaa4 X-Archives-Hash: fc834a368a63686210a04193a98e5921 On 12/23/2013 12:39 PM, Timur Aydin wrote: > On 12/23/13 18:12, Michael Orlitzky wrote: >> Anything you can provide, it's not clear to the rest of us how many >> computers are involved. Is the web/mail server only the gatway, or is >> that the workstation that you're using (when, for example, trying to >> access the website)? > > This is my home network, 10.2.0.0/16. Multiple computers with > Windows/Linux/Mac. On some subnets, I have gadgets that also need access > to the internet. > > The linux PC is the internet gateway with a static IP from my ISP. But > it is also used as my Linux workstation. The web server and email server > must be accessible from the internet and they are accessible if the > tunnel isn't up. > >> What IP address are you using to access the web server? Its internal >> one, or its external one? Is the website supposed to be visible externally? > > I can access both the web server and the mail server from the internal > network, no problems there. But, when the VPN tunnel comes up, all > external accesses stop working. > Ah, OK. Suppose the external IP address of your gateway is 1.2.3.4. Then that's the external address of your web/mail server as well. As a visitor, if I send a packet to 1.2.3.4, I get a response from 1.2.3.4, and everything is great. When you turn on the VPN on the gateway, it begins routing all outgoing traffic through some host in the USA. Now, as a visitor, if I send a packet to 1.2.3.4, here's what happens: me -> 1.2.3.4 (request) -> Your server's VPN IP (response) -> VPN server in the USA (response) -> me Now my TCP/IP stack wonders what a random packet from the USA is doing, and drops it, because I expected a response from 1.2.3.4. To see why there's no simple fix for this, imagine what happens if someone at Netflix HQ tries to visit your website via 1.2.3.4. If your routes would send the response back over 1.2.3.4, then they would also send your browser traffic there over 1.2.3.4. But that won't work. And if your routes would send your browser traffic over the VPN, then the web server response will go over the VPN as well. And that breaks the website. The not-simple solutions are probably going to involve reorganizing your network a bit; having a workstation, web server, and VPN client all on one box is giving you conflicting requirements. But maybe if you're lucky, you have a static public IP address on the VPN. In that case you can always access the website via the VPN address.