OpenVPN server (win32) wrong Netmask

Hi,

I have installed OpenVPN on a Windows 2000 SP4 machine (using the
openvpn-2.0.5-install.exe). The machine should act as a OpenVPN Server

It almost works, the IP of the TAP Device is set to 10.18.0.1 .. but
the Netmask keeps being set to 255.255.255.253, which I don't want. I
would like a Netmask 255.255.255.240 or at least 255.255.255.0 !

Does anybody know how I can change this?

The whole thing almos works, there is 1 Client machine connecting
(10.18.0.6) and I can ping it... but I cannot configure the router on
the windows machine becaus the adapter has the wrong netmask.

The Tap-Device is configured to "automatic" and it is useless to set
the values there directly, because OpenVPN always changes it back to
10.18.0.1/255.255.255.253

I start OpenVPN via console:

------------------------
"D:\Program Files\OpenVPN\bin\openvpn.exe" --pause-exit --config
"D:\Program Files\OpenVPN\configserver1018\server.ovpn"
------------------------

The config file server.ovpn looks like this:

------------------------
local 192.168.178.88
port 2394
proto udp
dev tun
dev-node tap1018

ca D:\\Program Files\\OpenVPN\\configserver1018\\ca.crt
cert D:\\Program Files\\OpenVPN\\configserver1018\\ibm.crt
key D:\\Program Files\\OpenVPN\\configserver1018\\ibm.key
dh D:\\Program Files\\OpenVPN\\configserver1018\\dh1024.pem


# Why does this not set the netmask on the adpapter correctly?
server 10.18.0.0 255.255.255.240

# I also tried the following but it was either ignored or the server
didn't want to start
#ifconfig 10.18.0.1 255.255.255.240
#ifconfig-pool 10.18.0.1 10.18.0.15

# I also tried this:
# ip-win32 manual
# and then set the adpater manually to a netmask of 255.255.255.240
(and ip of 10.18.0.1 of course)
# but it was ignored, it was then set again to 255.255.255.253

ifconfig-pool-persist ipp.txt

keepalive 10 120

comp-lzo

persist-key
persist-tun


status openvpn-status.log

log-append openvpn.log

verb 9
------------------------

It would be great if anyone can help :-)
Thank you very much!

Robert

Robert Eisig wrote:
> Hi,
>
> I have installed OpenVPN on a Windows 2000 SP4 machine (using the
> openvpn-2.0.5-install.exe). The machine should act as a OpenVPN Server
>
> It almost works, the IP of the TAP Device is set to 10.18.0.1 .. but
> the Netmask keeps being set to 255.255.255.253, which I don't want. I
> would like a Netmask 255.255.255.240 or at least 255.255.255.0 !
>
> Does anybody know how I can change this?

Something does not match here.

The TAP device is a layer 2 device, creating an Ethernet-like
tunneling interface, but it seems that you're not doing any
layer 2 linking, called bridging.

The IP layer (layer 3) tunnel device is TUN. It will have
an IP address and netmask. The tunnel is a point-to-point
connection, so a narrow netmask is enough, if you do not
have extra routing tricks, e.g. proxy ARP.

Why do you need a wider netmask?

--

Tauno Voipio
tauno voipio (at) iki fi

Thank you very much for your reply. I can see now a little clearer, but
still need some insights.

The device is working as a tun device, not as tap as I wrote, sorry!

In the meantime I changed the server statement in the server openvpn
config to:

server 10.18.0.0 255.255.255.248

This is my configuration now:

[----Laptop----]
(192.168.178.23)-\
\
(10.18.0.6)--(10.18.0.1)(192.168.178.88)--(192.168.178.1)---Internet
[-serverA-] [--------server1----------] [--DSL-ROUTER-]

I can ping from serverA at 10.18.0.6 to server1 at 10.18.0.1.
I can also ping the other direction.

10.18.0.1 can also be accessed from my LAN (192.168.178.0/24), because
I run a routing
software on server1 and I entered routing information to the DSL
router.

But now I need to access 10.18.0.6 also from my LAN and vice versa. Do
I need to change
something in the config files of OpenVPN now? (Some sort of bridging or
something?)

Or is it just enough to enter a new routing information in the DSL
router 192.168.178.1 and also
configure the routing software that is running on 192.168.178.88?

What confuses me, is that the address of the adapter 10.18.0.1 and the
subnet-netmask there
(255.255.255.253) do not include the 10.18.0.6.

How does openvpn manage that 10.18.0.6 is accessible from server1,
although it is not in
the range of 10.18.0.0/255.255.255.253?

I wonder how the routing software will know that 10.18.0.6 must be
addressed through 10.18.0.1, as it is not included in the range that
results from the netmask.

Thank you very much for your help!
Robert

Robert Eisig wrote:
> Thank you very much for your reply. I can see now a little clearer, but
> still need some insights.
>
> The device is working as a tun device, not as tap as I wrote, sorry!
>
> In the meantime I changed the server statement in the server openvpn
> config to:
>
> server 10.18.0.0 255.255.255.248
>
> This is my configuration now:
>
> [----Laptop----]
> (192.168.178.23)-\
> \
> (10.18.0.6)--(10.18.0.1)(192.168.178.88)--(192.168.178.1)---Internet
> [-serverA-] [--------server1----------] [--DSL-ROUTER-]
>
> I can ping from serverA at 10.18.0.6 to server1 at 10.18.0.1.
> I can also ping the other direction.
>
> 10.18.0.1 can also be accessed from my LAN (192.168.178.0/24), because
> I run a routing
> software on server1 and I entered routing information to the DSL
> router.
>
> But now I need to access 10.18.0.6 also from my LAN and vice versa. Do
> I need to change
> something in the config files of OpenVPN now? (Some sort of bridging or
> something?)
>
> Or is it just enough to enter a new routing information in the DSL
> router 192.168.178.1 and also
> configure the routing software that is running on 192.168.178.88?

Yes. If the DSL router is the default gateway for the other
hosts (here: the laptop), it suffices to have a route to the
10.18.0.x network in the router. Currently, it does not know
where the 10.18.0.x network is, and it probably attempts to
send its packets to the ISP.

The server1 routing should not need any changes: it already
seems to know how to reach serverA.

If the DSL box is Linux:

route add -net 10.18.0.0/29 gw 192.168.178.88

or just a host route:

route add -host 10.18.0.6 gw 192.168.178.88


> What confuses me, is that the address of the adapter 10.18.0.1 and the
> subnet-netmask there
> (255.255.255.253) do not include the 10.18.0.6.

The .253 in the netmask is obviously wrong: the netmasks must
have ones at the MSB end and zeroes at the LSB end. The nearest
correct netmask is .252.

You're right: The netmask should end with .248.

> How does openvpn manage that 10.18.0.6 is accessible from server1,
> although it is not in
> the range of 10.18.0.0/255.255.255.253?

Check if there is a host route to 10.18.0.6 with the tun0 interface
in the routing table of server1:

route -n


> I wonder how the routing software will know that 10.18.0.6 must be
> addressed through 10.18.0.1, as it is not included in the range that
> results from the netmask.

It does not - see above.

--

Tauno Voipio
tauno voipio (at) iki fi

Your answer helps me a lot to get more clarity.

Laptop and server1 are both windows 2000 machines. Server A is Debian
and Dsl-Router is a router box with a web-admin interface but it is
running linux inside.

I startet reading out and manipulating the routing tables on laptop and
server1.

But, the most interesting discovery is the following:

On server1 there is some interesting configuration, as soon as the
OpenVPN adapter si starting up. Let's have a look at the routing table
of server1:

Target Netmask Gateway Interface
0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.88

10.18.0.0 255.255.255.252 10.18.0.1 10.18.0.1

10.18.0.0 255.255.255.248 10.18.0.2 10.18.0.1

10.18.0.1 255.255.255.255 127.0.0.1 127.0.0.1

10.18.0.6 255.255.255.255 10.18.0.2 10.18.0.1

10.255.255.255 255.255.255.255 10.18.0.1 10.18.0.1

127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1

192.168.178.0 255.255.255.0 192.168.178.88 192.168.178.88

192.168.178.88 255.255.255.255 127.0.0.1 127.0.0.1

192.168.178.255 255.255.255.255 192.168.178.88 192.168.178.88

255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1


Standardgateway: 192.168.178.1


So there seems to be a new hidden Gateway 10.18.0.2, and this seems to
be responsible for reaching 10.18.0.6

But tracert 10.18.0.6 looks like this:

D:\>tracert 10.18.0.6

Routenverfolgung zu SERVERA [10.18.0.6] über maximal 30 Abschnitte:

1 78 ms 94 ms 109 ms AERVERA [10.18.0.6]

When I add a route on the dsl-router (192.168.178.1) to enable me to
reach 10.18.0.6
through 192.168.178.88 this does not help.

This is the routing Table of 192.168.178.1
(which is the Gateway for server1 and laptop):

10.18.0.0 255.255.255.252 192.178.178.88
10.18.0.0 255.255.255.248 192.168.178.88

After trying to reach 10.18.0.6 from laptop (192.168.178.23) with no
success, the routing table on laptop looks like this:

Aktive Routen:
Target Netzwerkmaske Gateway Interface
0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.23
10.18.0.1 255.255.255.255 192.168.178.88 192.168.178.23
10.18.0.2 255.255.255.255 192.168.178.88 192.168.178.23
10.18.0.6 255.255.255.255 192.168.178.88 192.168.178.23
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
192.168.178.0 255.255.255.0 192.168.178.23 192.168.178.23
192.168.178.23 255.255.255.255 127.0.0.1 127.0.0.1
192.168.178.255 255.255.255.255 192.168.178.23 192.168.178.23
255.255.255.255 255.255.255.255 192.168.178.23 192.168.178.23
Standardgateway: 192.168.178.1

But Ping and Tracert form laptop works only to 10.18.0.1, not to
10.18.0.6:

D:\>tracert 10.18.0.1
Routenverfolgung zu SERVER1 [10.18.0.1] ber maximal 30 Abschnitte:
1 <10 ms <10 ms <10 ms SERVER1 [10.18.0.1]

D:\>tracert 10.18.0.6
Routenverfolgung zu 10.18.0.6 ber maximal 30 Abschnitte
1 * * * Zeitberschreitung der Anforderung
(timeout!)

Did I miss something?

Or maybe the DSL Router 192.168.178.1 does not do the routing
correctly, I am thinking about hacking it, it is a linux box inside as
I mentioned before.

Any ideas?

Thank You very much
Robert

Robert Eisig wrote:
> Your answer helps me a lot to get more clarity.
>
> Laptop and server1 are both windows 2000 machines. Server A is Debian
> and Dsl-Router is a router box with a web-admin interface but it is
> running linux inside.
>
> I startet reading out and manipulating the routing tables on laptop and
> server1.
>
> But, the most interesting discovery is the following:
>
> On server1 there is some interesting configuration, as soon as the
> OpenVPN adapter si starting up. Let's have a look at the routing table
> of server1:
>
> Target Netmask Gateway Interface
> 0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.88
>
> 10.18.0.0 255.255.255.252 10.18.0.1 10.18.0.1
>
> 10.18.0.0 255.255.255.248 10.18.0.2 10.18.0.1
>
> 10.18.0.1 255.255.255.255 127.0.0.1 127.0.0.1
>
> 10.18.0.6 255.255.255.255 10.18.0.2 10.18.0.1
>
> 10.255.255.255 255.255.255.255 10.18.0.1 10.18.0.1
>
> 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
>
> 192.168.178.0 255.255.255.0 192.168.178.88 192.168.178.88
>
> 192.168.178.88 255.255.255.255 127.0.0.1 127.0.0.1
>
> 192.168.178.255 255.255.255.255 192.168.178.88 192.168.178.88
>
> 255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1
>
>
> Standardgateway: 192.168.178.1
>

I just wonder where this mess comes from ...

I clipped most, as I'm going to make a short summary of
the basic tunneling and routing.

An IP tunnel has two sets of addresses: the tunnel inside
and the tunnel outside at both ends. The outside addresses
are used in the public network to connect the tunnel ends
together. The outside addresses include the transport layer
protocol (UDP preferred) and the transport layer port (if
present in the protocol, OpenVPN: UDP/1194).

The inside addresses are for the data transported in the tunnel.
They depend on the tunnel type: For TAP they are the pseudo-MAC
addresses of the tapx interfaces, for TUN they are the IP addresses
and netmasks associated with the tunx interfaces.

When doing basic routing (no load balancing etc), the route
table can be imagined to be sorted in descending netmask order.
This makes the tightest netmasks appera first to the route
handler, and the last one is 0.0.0.0 for the default route.

A destination is masked with the netmask and compared with
the target on the route, each in turn. The first that matches
will be taken, and if no specific match is found, the default
route matches, as both the target and mask are zeroes.

To take the table above as an example:

Target Netmask Gateway Interface
1 10.18.0.1 255.255.255.255 127.0.0.1 127.0.0.1
2 10.18.0.6 255.255.255.255 10.18.0.2 10.18.0.1
3 10.255.255.255 255.255.255.255 10.18.0.1 10.18.0.1
4 192.168.178.88 255.255.255.255 127.0.0.1 127.0.0.1
5 192.168.178.255 255.255.255.255 192.168.178.88 192.168.178.88
6 255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1
7 10.18.0.0 255.255.255.252 10.18.0.1 10.18.0.1
8 10.18.0.0 255.255.255.248 10.18.0.2 10.18.0.1
9 192.168.178.0 255.255.255.0 192.168.178.88 192.168.178.88
10 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
11 0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.88

For a Linux routing table, there is plenty of extra. This looks
like somebody has copied everything from a Windows route table.

I numbered the lines for clarity, they are not part of route
command output.

The lines 1, 3, 4, 5, 6, 7 and 10 are unnecessary (and misleading).
If line 7 is deleted, line 2 gets unnecessary, too.
The line 8 is incorrect: there should be no gateway, only the
local tun interface directly (10.18.0.1, I guess).

Below is a pretty complicated tunneling table from one of my routers,
handling internal network NAT and OpenVPN tunneling:

tauno@miranda:~$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Iface
172.19.23.2 0.0.0.0 255.255.255.255 UH tun0
172.29.29.28 0.0.0.0 255.255.255.252 U eth0
172.17.23.0 0.0.0.0 255.255.255.0 U eth1
172.19.23.0 172.19.23.2 255.255.255.0 UG tun0
80.222.32.0 0.0.0.0 255.255.240.0 U eth0
0.0.0.0 80.222.32.1 0.0.0.0 UG eth0

I deleted the Metric, Ref and Use columns to fit the line length.

eth0 is connected to ADSL which has an address in the 80.222.32.x range.
eth1 is connected to the internal network.
The 172.29.29.28 network is only for controlling the operator
interface of the ADSL box.
The 172.19.23.x network is transported inside the tunnel.

----

Is this of any help?

--

Tauno Voipio
tauno voipio (at) iki fi

Dear Tauno,

I decided to make a seperate tunnel to every client in my lan who needs
it. This is somehwo stupid but I have lost so much time now and I have
to go on. This means I gave up to solve my actual routing problem.

I learned so much from your postings and I am still integrating the new
insights. I will use this knowledge because I will extend this private
network in the very near future. I want to use more linux machines as
routers as I got the impression that windows routing confuses me too
much.

The next thing I am going to do is to route a MS SQL Server Connection
through a linux machine and then to another LAN via OpenVPN and create
an ODBC-Connection on the client machine.

Greetings
Robert

Well, it does not work :-(

This is my setup:


[MsSqlServer](192.168.0.5)---(192.168.0.210)[Linux](10.210.0.1)---(10.210.0.6)[WinClient]



On [Linux] (the "router") I added this into the firewall script:

iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 1433 -j DNAT
--to-destination 192.168.0.5
iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 10.210.0.6 -j SNAT
--to-source 10.210.0.1


tun0 is the interface of the 10.210.0.0/24 subnet (which is an OpenVNC
tunnel), Ping and everything between 10.210.0.1 and 10.210.0.6 works
fine.

On Winclient I am trying to create an ODBC connection to 192.168.0.5 (I
enter 10.210.0.1 as the MS SQL Server IP.

With my iptables-rule the Linux machine should forward requests from
10.210.0.6 on port 1433 to 192.168.0.5... shouldn't it?

ODBC just says "General network error." (I hope I translated this
correctly) when I try to connect.

It would be very kind if someone could help
Thank you
Robert

Robert Eisig wrote:
> Well, it does not work :-(
>
> This is my setup:
>
>
> [MsSqlServer](192.168.0.5)---(192.168.0.210)[Linux](10.210.0.1)---(10.210.0.6)[WinClient]
>
>
>
> On [Linux] (the "router") I added this into the firewall script:
>
> iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 1433 -j DNAT
> --to-destination 192.168.0.5
> iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 10.210.0.6 -j SNAT
> --to-source 10.210.0.1
>
>
> tun0 is the interface of the 10.210.0.0/24 subnet (which is an OpenVNC
> tunnel), Ping and everything between 10.210.0.1 and 10.210.0.6 works
> fine.

If the 10.210.0.x addresses belong to the tunnel inside,
just add routes:

- tell the Windows box that 192.168.0.5 is reachable
via 10.210.0.1 at the tun interface,

- tell the SQL server that the 10.210.0.x net is reachable
via the Linux box (192.168.0.210).

- delete the address fudges above.

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:

> - delete the address fudges above.

You mean I should remove the 2 IPTABLES lines?

> iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 1433 -j DNAT
> --to-destination 192.168.0.5
> iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 10.210.0.6 -j SNAT
> --to-source 10.210.0.1

I will try this and add the routes as soon as I get access to the SQL
Server machine.

Thank you
Robert