# I have a little glitch in my OpenVPN configuration.

One of the subjects which I have written about before, is that I host a VPN, which uses the OpenVPN protocol, and that I have used my own, hand-written configuration files for it.

There are certain ways in which this VPN is atypical, in its configuration. For example, what most system administrators will do, is assign a range of IP addresses on their virtual LAN, which do not overlap anywhere with the IP address range on their physical LAN. OTOH, what I have done is to use the configuration lines:


ifconfig 192.168.2.129 255.255.255.128
ifconfig-pool 192.168.2.130 192.168.2.254 255.255.255.0
push "route-gateway 192.168.2.129 255.255.255.0"

In my thoughts, I was assigning the IP address range from 192.168.2.129 through 192.168.2.254 to the VPN. But whenever my OpenVPN server starts or restarts it does so with a warning, that this IP address range overlaps with the existing IP addresses of my physical LAN, which go from 192.168.2.0 through 192.168.2.255 .

This is how I made a little mistake: My configuration unwittingly also included IP address 192.168.2.255 in the range, which will be routed as belonging to the VPN. And this is due to the first line above, which simply has 255.255.255.128 as its subnet mask.

This can cause the following problem. As part of my physical LAN, address 192.168.2.255 sometimes serves a purpose. It is the UDP Broadcast address of my router, and can be used by clients to find all the connected LAN clients.

Probably because I have done this, the command ‘nmblookup‘ will not work on my machine ‘Phoenix’, which is also my server (as I discovered for the first time last evening). But beyond that, this could be why setting this server to act as a WINS server creates a failure in the configuration of my LAN. This may not really be due to any intolerance on the part of my Windows 7 machine ‘Mithral’, of a Linux box acting as a WINS server.

Also, the command ‘nmblookup‘ works fine on both the other Linux machines on my LAN: On ‘Klystron’ and on ‘Walnut’.

If I was determined to make my configuration better, I could try tweaking this OpenVPN configuration, let us say with a subnet mask of 255.255.255.192 instead of with 255.255.255.128 . Of course, I would then also have to reduce the number of possible, available connections to my VPN accordingly, let us say so:


ifconfig 192.168.2.129 255.255.255.192
ifconfig-pool 192.168.2.130 192.168.2.191 255.255.255.0
push "route-gateway 192.168.2.129 255.255.255.0"



In other words, I can create a 6-bit subnet, the addresses of which are prepended by the bits ’10’. However, it was incorrect of me to have a 7-bit subnet, which was simply prepended by the high bit ‘1’, because unfortunately, doing so also masks the UDP Broadcast Address of the router.

For the moment, not being able to use the ‘nmblookup‘ command on ‘Phoenix’ has not had significant consequences for me, and one main reason might be the fact that in general, Linux avoids using NetBIOS. Also, the graphical browser I use, does not seem to depend 100% on this command, or on the local machine being the WINS server, in order to work.

So this error has little urgency for me, and also did not impede my use of the computers.

Dirk

(Edit : ) Minutes after writing this posting, I have applied the change in configuration as described. With great joy, I find that my ‘nmblookup‘ command works fine now.

Now, this error should not strike people as serious, because it was only according to the LAN, as seen by one client (‘Phoenix’) that this address belonged, incorrectly, to the VPN. However, sometimes routers have been programmed in their firmware to offer as an extended feature, to reflect whatever IP address assignments are reported by one client. If mine is such a router, then of course, this one IP address would have been spotted as a conflict, and overridden by the router, so that the other machines on my LAN, continued to see the correct mapping.

Whenever I post about activities which I have pursued on my computer, I must take into account that the reader might want to duplicate any successes I have had, or learn from mistakes which I made – assuming those mistakes were caught. This follows from the fact that many people read the Internet, and blogs such as mine, sometimes as guides.

What the reader might want to take note of, is the description I gave earlier in this posting, according to which some VPNs only give access to an array of IP addresses, that exist in the memory of one server, and which are not shared with a physical LAN. The contrast might seem interesting, that I have been able to allow them to overlap.

Further, I have indicated that the IP address range of my VPN might exist without the awareness of my router. I.e., If I ping a machine on my LAN from my VPN, the outgoing Ping-Packet does not just need to find its way to that ‘other machine’, but the response of the other machine did also find its way back to the VPN, and eventually, back to the client which I used to connect to my VPN server, from someplace outside my LAN.

An astute reader might notice that there is an implementation detail missing from my earlier descriptions, without which any attempts by the reader to duplicate these results would fail.

With IPv4 addresses, there exists such a thing as ‘NAT’ – Network Address Translation. Each packet that gets transmitted over the Internet, either via TCP or UDP, does not just possess a To address (IP number), but additionally a From address. One important aspect of what NAT does, is to alter the electronic From address of each packet, to point back to a host address, that previously pointed back to a guest / subnet address. That way, when the receiving computer responds to the modified packet, it will send its response back to the address on the host network, even though the outgoing request originated on a guest network.

In the case of common routers, the host network would be the WAN, while the guest network would be the LAN. But in the case of a VPN, this distinction becomes arbitrary.

And so under Linux, we have the amazing ability to modify this behavior at the kernel-level, by executing a script in root mode, which is called an ‘IP-Table’. If the reader wants to duplicate this successfully, I recommend that he first read other references which specifically deal with IP-Tables under Linux. I do not know how to do this under Windows.

But I specifically have a custom script in the file ‘/etc/ip6tables.list‘, which goes something like this:


#!/bin/sh

# Let's save typing and confusion with variables
IPTABLES=/sbin/iptables
IP=/sbin/ip
IP6TABLES=/sbin/ip6tables

(...)

# Flush active rules and custom tables
$IPTABLES --flush$IPTABLES -t mangle -F
$IPTABLES -t nat -F$IPTABLES --delete-chain

# Ditto for IPv6
$IP6TABLES --flush #$IP6TABLES -t mangle -F
#$IP6TABLES -t nat -F #$IP6TABLES --delete-chain

# Set defaults
$IPTABLES -P INPUT ACCEPT$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT$IP6TABLES -P INPUT DROP
$IP6TABLES -P FORWARD ACCEPT$IP6TABLES -P OUTPUT ACCEPT

(...)

$IPTABLES -I INPUT 1 -i tun+ -j ACCEPT$IPTABLES -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

(...)




I should point out a few facts about my approach:

1. The use of a custom iptables.list file such as mine is becoming deprecated. More and more packaged Linux software uses its own IP-Tables, with which my example would need to be integrated, not left in its own file.
2. The full version of my IP-Tables script includes sensitive details which I feel are important to the security of my server, and which I have omitted here for that reason.
3. My full IP-Tables script additionally stops certain services, which make their own entries, before flushing the tables, and then my script also restarts those services, after making these entries. Obviously, none of this might be applicable to the context of the reader, unless he or she also has exactly the same IP-Tables-aware services installed as I do. And again, this way to deal with those services is awkward, because if the services needed to be uninstalled, or new ones like them installed, then this script of mine would also need to be edited, in places not shown here for clarity.

The important detail to draw the attention of the reader to was



$IPTABLES -I INPUT 1 -i tun+ -j ACCEPT$IPTABLES -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE




These are the magic instructions to my kernel, which state in English, ‘If any packets have come from one of the tunnel devices, accept them. And if any packets have been routed in such a way, that they get sent out to my LAN via the physical Networking Interface, apply the masquerade. This masquerade is to edit their return-address to the current IP address of this computer, in place of the return-address on the VPN, where the packets came from, belonging to the tunnel device. Any actual routing is assumed to have been initiated by the OpenVPN server, not this script.’

Without this additional detail, I was not able to get my VPN to work as I wanted. And AFAIK, the main reason is the fact that my router is still only aware, of one physical interface with my computer, that is acting as my VPN server. My router is not aware of any VPN that exists in the electronic mind of this computer.

Packets must ultimately be sent back that that VPN, in response to whatever requests originated there.

(Edit 11/13/2016 : ) I should add, that since I first activated this VPN, I have undergone numerous router-upgrades. The configuration which I described above was needed, to get this to work on a Bell 2Wire Modem. Since then, I have been upgraded to a Bell Fibe Modem, which may or may not additionally have received a firmware upgrade on November 9.

Most recently, I have discovered that I can actually Ping address 192.168.2.129 from other machines on my real, physical LAN, even though this address squarely belongs to the VPN. This would seem to suggest that the updated router is aware, of how to route packets back to IP addresses, which an individual computer claims to possess, but which were not assigned to that computer by the DHCP server of the router.

If that was true 100%, then the IP masquerade should also not be necessary anymore. It was necessary several years ago.

In such cases, I aim not to try repairing anything that already works, so that I am keeping this additional detail for now.

This site uses Akismet to reduce spam. Learn how your comment data is processed.