[SOLVED] Unable to access servers on vpn network.

[mnickerson]

This setup takes place entirely between vmware images residing on a single system. My goal is have clients VPN into the 10.20.20.0/24 network and be able to access any device on that network. It would be nice if the clients are assigned a 10.20.20.x IP address, but I don’t see how that could be done without using bridging, which I’d prefer to avoid.

VPN server has 2 NICs

Outside interface, eth0, on the vpn server is 10.50.0.48/24
Inside interface, eth1, on the vpn server is 10.20.20.10
tun0 interface ip is 192.168.1.1

I have a file server on 10.20.20.100 that I want clients that have established a VPN, to have access to.

client IP address on eth0 is 10.50.0.77,
client tun0 adapter IP is 192.168.1.6

the file server is 10.20.20.100/24 gw is 10.20.20.10, the eth1 on the vpn server.


Currently, clients can establish a connection, and ping the interface at 10.20.20.10, but not the file server at 10.20.20.100
The file server can ping the vpn server at 10.20.20.10, but none of the clients. The file server can also ping 10.50.048, the eth0 interface of the vpn server.

The vpn server can ping everyone.

Route table on vpn server (10.50.0.48 eth0, 10.20.20.10 eth1, 192.168.1.1 tun0 ):

Code: Select all

 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.2     *               255.255.255.255 UH    0      0        0 tun0
10.20.20.0      192.168.1.2     255.255.255.252 UG    0      0        0 tun0
10.20.20.0      *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     192.168.1.2     255.255.255.0   UG    0      0        0 tun0
localnet        *               255.255.255.0   U     0      0        0 eth0
default         10.50.0.1       0.0.0.0         UG    100    0        0 eth0

route on file server (10.20.20.100)

Destination Gateway Genmask Flags Metric Ref Use Iface
10.20.20.0 * 255.255.255.255 U 0 0 0 eth0
default 10.20.20.10 0.0.0.0 UG 100 0 0 eth0

route on client (10.50.0.77eth0, 192.168.1.6 tun0)

192.168.1.5 * 255.255.255.255 UH 0 0 0 tun0
10.20.20.0 192.168.1.5 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 192.168.1.5 255.255.255.0 UG 0 0 0 tun0
10.50.0.0 * 255.255.255.0 U 1 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth0
default 10.50.0.1 0.0.0.0 UG 0 0 0 eth0

server.conf

Code: Select all

local 10.50.0.48
port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 192.168.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.20.20.0 255.255.255.0"
client-to-client
client-config-dir ccd
route 10.20.20.0 255.255.255.252
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

client.conf

Code: Select all

client
dev tun
proto udp
remote 10.50.0.48 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca ca.crt
cert matt-desktop.crt
key matt-desktop.key
ns-cert-type server
comp-lzo
verb 3

The 10.20.20.0 network doesn't use a router. Clients just access it and go directly via ip address to the target servers. So my thought is that this is a routing issue, but I don’t see where the problem is.

[krzee]

You can not give the vpn clients IPs in an already existing subnet, the VPN should have its own subnet.

Your intuition seems to be correct... sounds like a routing issue. Namely the machines on the LAN have no return route to the vpn.
http://www.secure-computing.net/wiki/index.php/Graph is an illustration of the issue.
https://www.secure-computing.net/wiki/i ... PN/Routing has a section named "ROUTES TO ADD OUTSIDE OPENVPN" in which i describe the issue and what must be done to fix it.
Hope that helps.

[mnickerson]

If I'm reading your examples correctly the problem is the in routing of the 196.168.1.0 subnet

Code: Select all

192.168.1.2     *               255.255.255.255 UH    0      0        0 tun0
10.20.20.0      192.168.1.2     255.255.255.252 UG    0      0        0 tun0
10.20.20.0      *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     192.168.1.2     255.255.255.0   UG    0      0        0 tun0

So the ping request from the client, tun0 192.168.1.6, is sent to the file server 10.20.20.100, which attempts to reply to 192.168.1.6. The ping is sent to the default gateway of the fileserver, 10.20.20.10 (this is also the vpn server). The vpn server, because it's acting as the default gateway for the 10.20.20.x network, should have a route to the tun0 interface and be able to pass the ping request to the VPN client @ tun0 196.168.1.6.

I can ping 192.168.1.1 from the file server.

I added these lines:
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

However this just causes duplicate entry errors on the client and server.

Perhaps the routing is correct, and the problem lies in the forwarding on the vpn server.

[mnickerson]

Looks like I solved it with forwarding changes.

Code: Select all

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j ACCEPT 
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT 
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -j ACCEPT 
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT

I had the INPUT line set previously, per the documentation, and set echo 1 > .......ip_forward. Looks like I needed to add these additional FORWARD lines, to make everything work correctly.

[krzee]

thank you for sharing your solution =]