Bill VB's questions

For context, I am migrating my VPN server. I duplicated the old set up almost exactly, and now clients connected to the new VPN server cannot tunnel properly (but they connect just fine).

While tunneled, this is the routing table of my client:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
[vpnserver-ip]  10.105.0.1      255.255.255.255 UGH       0 0          0 wlan1
10.105.0.0      0.0.0.0         255.255.252.0   U         0 0          0 wlan1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 wlan1
0.0.0.0         10.8.0.5        128.0.0.0       UG        0 0          0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG        0 0          0 tun0
0.0.0.0         10.105.0.1      0.0.0.0         UG        0 0          0 wlan1

At the same time, here is the routing table of the server

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         [vpn-gate].1    0.0.0.0         UG        0 0          0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
[vpn-sub].0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

The table of the new VPN server is basically identical to that of the old one, so I'm not sure what is missing? Why won't this tunnel properly?

I've redacted the IP of the VPN server.

On the logs to one of my websites, I always track the client's browser and OS. Every so often I see one with MSIE 6.0 and usually the http_referer field being blank. Since MSIE 6 doesn't exist in the wild anymore, would a good policy simply be to redirect all clients whose user agent contains "MSIE 6.0" to someplace else (as well as all clients whose user agent is blank)?

Thanks in advance.

I'm trying to figure out whether the host network I am on is injecting TCP Resets into my VPN connection.

I have a personal OpenVPN server, and recently my attempts to connect over TCP port 1194 have been strangely interrupted by TCP reset messages, causing the OpenVPN client to enter a reboot-loop. I suspect the local network infrastructure does not like this, and is trying to block it. After changing the port to 1195 this issue disappears entirely, indicating this isn't just some bug in the openVPN client or server.

So my question is this: Is this mysterious injection of TCP resets a common trick to block unwanted connections? It seems a little strange -- why don't they just block the port or send other TCP control messages to terminate the connection? Last week, I was connecting over TCP to port 1194 without issue. The strange TCP resets just appeared this week.

Thanks in advance!

I have a personal OpenVPN server out on "the tubes". Last week, I was able to connect without incident and with very good performance. This week, when I manage to connect, the client seems to enter a "reboot loop".. the output as follows:

Fri Apr 13 11:20:55 2012 OPTIONS IMPORT: timers and/or timeouts modified
Fri Apr 13 11:20:55 2012 OPTIONS IMPORT: --ifconfig/up options modified
Fri Apr 13 11:20:55 2012 OPTIONS IMPORT: route options modified
Fri Apr 13 11:20:55 2012 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Apr 13 11:20:55 2012 Preserving previous TUN/TAP instance: tun1
Fri Apr 13 11:20:55 2012 Initialization Sequence Completed
**Fri Apr 13 11:21:00 2012 Connection reset, restarting [0]**
Fri Apr 13 11:21:00 2012 TCP/UDP: Closing socket
Fri Apr 13 11:21:00 2012 SIGUSR1[soft,connection-reset] received, process restarting
Fri Apr 13 11:21:00 2012 Restart pause, 5 second(s)

Every few seconds, this set of messages repeats itself. Note the line I emphasized with the **. Is the local organizations's network I'm on resetting this TCP connection? The funny thing is, I can still connect to my VPN, but it's very, very slow. I think what's happening is that it gets only a few seconds at a time. Has anyone seen anything like this before, is my hypothesis true? If so, what alternatives are there? Using UDP instead of TCP, or perhaps a different port?

Let A.B.C.D be the public IP of my VPN server. Let W.X.Y.Z be the IP of the client before it connects to the VPN.

My VPN server's IP address on the LAN in 10.8.0.1, and the client is 10.8.0.6. I also run a webserver on the same machine hosting the VPN. On it is a simple webpage that performs the exact same thing as whatismyip.org (i.e., simply prints the IP of the requester)

Let me illustrate the scenario for you.

In a Chrome window I have three tabs, what I have in parenthesis is the URL:

• Tab 1 (http://whatismyip.org):

  A.B.C.D

  This is what I expect to see. It's the public IP of the VPN server.

• Tab 2 (http://10.8.0.1):

  10.8.0.6

  ok, looks expected. They are behind the same LAN now.

• Tab 3 (http://A.B.C.D)

  W.X.Y.Z

  WTF?? Basically, if I access the webserver while tunneled, in shows the IP address of my machine PRIOR to tunelling!

Remember, tab2 and tab3 are the same webpage. Why does Tab3 not show the client IP as it's own IP (i.e., show A.B.C.D)???

I hope this question is clear, thanks in advance!

I have set up a working OpenVPN server and client, and can apparently connect to each other just fine.

I'm trying to route all of the clients traffic (web+DNS) through the VPN server, however it isn't working. Per the OpenVPN tutorial, I'm doing:

sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

And this apparently does nothing. Once connected to the VPN, the client can ping the server just fine, but has absolutely no Internet access.

Doing

sudo iptables -S or sudo iptables -L

doesn't look like anything has changed.. I've changed the server and client config files per the tutorial's instructions.

Any help would be great, thanks.

Update

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.8.0.0/24          0.0.0.0/0           
MASQUERADE  all  --  10.8.0.0/24          0.0.0.0/0           
MASQUERADE  all  --  10.8.0.0/24          0.0.0.0/0           
MASQUERADE  all  --  10.8.0.0/24          0.0.0.0/0    

I have an Ubuntu server with a static IP for personal use on which I want to install a VPN server. There are a few [unhelpful] tutorials on installing openvpn on Ubuntu but they all are predicated on a bridged adapter. So my question has two parts:

1. Is it possible to set up a VPN server without a bridged adapter (i.e., all VPN clients will appear to have the same IP as the server)? Unless there are reasons I'm unaware of to make this a poor choice security-wise, this seems simplest option for me. However, virtually all tutorials pre-suppose you have a bridged adapter working.

2. It seems like instead of openvpn there is simply a pptp package in the Ubuntu reposities, and it requires only password-authentication. Naturally I'm a little wary of that and a quick browse on wikipedia showed that there are a number of vulnerabilities with PPTP. Does anyone recommend going down this path?

Thanks in advance, please pardon my ignorance on some aspects of this topic.

On my website, I have a "hidden" page that displays a list of the most recent visitors. There exist no links at all to this single PHP page, and, theoretically, only I know of its existence. I check it many times per day to see what new hits I have.

However, about once a week, I get a hit from a 208.80.194.* address on this supposedly hidden page (it records hits to itself). The strange thing is this: this mysterious person/bot does not visit any other page on my site. Not the public PHP pages, but only this hidden page that prints the visitors. It's always a single hit, and the HTTP_REFERER is blank. The other data is always some variation of

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; YPC 3.2.0; FunWebProducts; .NET CLR 1.1.4322; SpamBlockerUtility 4.8.4; yplus 5.1.04b)

... but sometimes MSIE 6.0 instead of 7, and various other plug ins. The browser is different every time, as with the lowest-order bits of the address.

And it's just that. One hit per week or so, to that one page. Absolutely no other pages are touched by this mysterious visitor.

Doing a whois on that IP address showed it's from the New York area, and from the "Websense" ISP. The lowest order 8 bits of the address vary, but they're always from the 208.80.194.0/24 subnet.

From most of the computers that I use to access my website, doing a traceroute to my server does not contain a router anywhere along the way with the IP 208.80.*. So that rules out any kind of HTTP sniffing, I might think.

How and why is this happening? It seems completely benign, but unexplainable and a little creepy.

I have an Ubuntu linux Linode server that I am trying to install OpenVPN on. I'm following the tutorials (which, it turns out, are quite incomplete).

auto br0
iface br0 inet static
        address 192.168.0.10
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

When I add this chunk in my /etc/network/interfaces, and I restart networking, my eth0 interface does not have an IP and I cannot get on the network (I need to use a buggy, slow, and annoying AJAX term to do damage repair).

Why does adding this screw everything up? Any tips on how to set up this bridged adapter??

Thanks in advance!