1 |
On 12/23/2013 12:39 PM, Timur Aydin wrote: |
2 |
> On 12/23/13 18:12, Michael Orlitzky wrote: |
3 |
>> Anything you can provide, it's not clear to the rest of us how many |
4 |
>> computers are involved. Is the web/mail server only the gatway, or is |
5 |
>> that the workstation that you're using (when, for example, trying to |
6 |
>> access the website)? |
7 |
> |
8 |
> This is my home network, 10.2.0.0/16. Multiple computers with |
9 |
> Windows/Linux/Mac. On some subnets, I have gadgets that also need access |
10 |
> to the internet. |
11 |
> |
12 |
> The linux PC is the internet gateway with a static IP from my ISP. But |
13 |
> it is also used as my Linux workstation. The web server and email server |
14 |
> must be accessible from the internet and they are accessible if the |
15 |
> tunnel isn't up. |
16 |
> |
17 |
>> What IP address are you using to access the web server? Its internal |
18 |
>> one, or its external one? Is the website supposed to be visible externally? |
19 |
> |
20 |
> I can access both the web server and the mail server from the internal |
21 |
> network, no problems there. But, when the VPN tunnel comes up, all |
22 |
> external accesses stop working. |
23 |
> |
24 |
|
25 |
Ah, OK. Suppose the external IP address of your gateway is 1.2.3.4. Then |
26 |
that's the external address of your web/mail server as well. As a |
27 |
visitor, if I send a packet to 1.2.3.4, I get a response from 1.2.3.4, |
28 |
and everything is great. |
29 |
|
30 |
When you turn on the VPN on the gateway, it begins routing all outgoing |
31 |
traffic through some host in the USA. Now, as a visitor, if I send a |
32 |
packet to 1.2.3.4, here's what happens: |
33 |
|
34 |
me -> 1.2.3.4 (request) |
35 |
-> Your server's VPN IP (response) |
36 |
-> VPN server in the USA (response) |
37 |
-> me |
38 |
|
39 |
Now my TCP/IP stack wonders what a random packet from the USA is doing, |
40 |
and drops it, because I expected a response from 1.2.3.4. |
41 |
|
42 |
To see why there's no simple fix for this, imagine what happens if |
43 |
someone at Netflix HQ tries to visit your website via 1.2.3.4. If your |
44 |
routes would send the response back over 1.2.3.4, then they would also |
45 |
send your browser traffic there over 1.2.3.4. But that won't work. And |
46 |
if your routes would send your browser traffic over the VPN, then the |
47 |
web server response will go over the VPN as well. And that breaks the |
48 |
website. |
49 |
|
50 |
The not-simple solutions are probably going to involve reorganizing your |
51 |
network a bit; having a workstation, web server, and VPN client all on |
52 |
one box is giving you conflicting requirements. But maybe if you're |
53 |
lucky, you have a static public IP address on the VPN. In that case you |
54 |
can always access the website via the VPN address. |