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.


Reply via email to