OpenVPN Server on Win2003 - outbound to client bypassing tun

[azmtnbike]

I am running OpenVPN as a server on a Windows system behind a firewall. I have a device (SIP phone) that is establishing the tunnel from outside the firewall through port mapping to my Windows system. The device sends its SIP packets correctly to the server which the server receives and attempts to respond.

The problem is that the server is sending the SIP response packet to its default gateway and not back through the OpenVPN tunnel.

My config for the server is as follows:

port 1199
dev tun
proto tcp
server 10.3.230.0 255.255.255.0
cipher AES-128-CBC
ca ca.crt
dh dh1024.pem
cert client1.crt
key client1.key
resolv-retry infinite
persist-key
persist-tun
keepalive 10 100
script-security 3 system
auth-user-pass-verify login.bat via-env
tls-exit
push "route 10.1.0.0 255.255.0.0"
push "route 10.3.222.0 255.255.255.0"
push "route 10.3.223.0 255.255.255.0"
push "route 10.3.224.0 255.255.255.0"
push "route 10.3.225.0 255.255.255.0"
client-cert-not-required
username-as-common-name


When Open VPN is enabled the following gets added to the Routes (displayed from Route Print):

Dest Netmask Gateway Interface Metric
10.3.230.0 255.255.255.252 10.3.230.1 10.3.230.1 30
10.3.230.1 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.3.230.1 10.3.230.1 30
224.0.0.0 240.0.0.0 10.3.230.1 10.3.230.1 30
255.255.255.255 255.255.255.255 10.3.230.1 10.3.230.1 1

The address assigned to my device is 10.3.230.6. Why is the netmask for 10.3.230.0 at 255.255.255.252? I thought the "server 10.3.230.0 255.255.255.0" would make the route the same. The TAP NIC also shows the 255.255.255.252 address.

Thanks for any help.

[azmtnbike]

I made some progress, but not sure I tackled it exactly right.

I added the following to my configuration of the server:

topology subnet
push "route 10.3.230.0 255.255.255.0"

I didn't think that the push "route..." was needed but didn't think it would hurt.

This did get me further. Now my client receives 10.3.230.2 as its IP and my Route Print on the server shows:

10.3.230.0 255.255.255.0 <--instead of 255.255.255.252

My IP phone can now send and receive from the server.

However, I fired up another phone and set it up the same except with a different username/passwd. It establishes the VPN successfully, but I am not seeing any packets from it. It shows that it was assigned 10.3.230.3, but I cannot ping it from the Server.

Was "topology subnet" the correct direction to take? It seems from documentation that it is designed to allow multiple clients.

Thanks for any guidance.

[azmtnbike]

It appears that the clients/phones are running 2.0 and I am running 2.3 on the Windows Server.

From what I have come across I have to skip the "topology subnet".

I was hoping that OpenVPN server would dish out the IP addresses from a pool and get the correct routing information to the clients. Prior to attempting this configuration I was doing just that on a pfSense router with OpenVPN.

At this point I understand where the 255.255.255.252 comes from and that the server is on the 10.3.230.0-3 range of addresses and is 10.3.230.1, and that my first client is on the next range at 10.3.230.4-7....

I can now ping the two clients at 10.3.230.6 and 10.3.230.10. After pushing the route 10.1.0.0 to the clients and define static routes in Windows for each client I added, I was able to establish communications both directions. Basically "route add 10.3.230.4 mask 255.255.255.252 10.3.230.2" and another for 10.3.230.8 on the Windows server. Here is my final config.

port 1199
dev tun
proto udp
server 10.3.230.0 255.255.255.0
cipher AES-128-CBC
ca ca.crt
dh dh1024.pem
cert server.crt
key server.key
resolv-retry infinite
persist-key
persist-tun
keepalive 10 100
script-security 3 system
client-to-client
auth-user-pass-verify login.bat via-env
tls-exit
push "route 10.1.0.0 255.255.0.0"
push "route 10.3.222.0 255.255.255.0"
push "route 10.3.223.0 255.255.255.0"
push "route 10.3.224.0 255.255.255.0"
push "route 10.3.225.0 255.255.255.0"
client-cert-not-required
username-as-common-name