[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Possible routing problem


  • Subject: Re: [Openvpn-users] Possible routing problem
  • From: john@xxxxxxxxx
  • Date: Sun, 9 Sep 2007 23:14:22 -0400 (EDT)
  • Importance: Normal

Date: Sun, 09 Sep 2007 18:35:20 -0700
From: "Daniel L. Miller" <dmiller@xxxxxxxxx>
Subject: Re: [Openvpn-users] Possible routing problem
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <46E49F58.7080504@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

john@xxxxxxxxx wrote:
> I recently set up openvpn between two lans and wanted clients on both sides
> to have full access to either side....
>
Thanks for the reply.

My openvpn server config follows - I think it's fairly straightforward:
server 172.27.0.0 255.255.0.0
tls-server
local 192.168.0.222
port 1195
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
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
keepalive 10 120
persist-key
ifconfig-pool-persist /etc/openvpn/customers-ip.txt
client-config-dir /etc/openvpn/ccd
status customers.log
log-append /var/log/openvpn-customers.log
verb 3
replay-window 72 30
comp-lzo
# route to a remote lan on a client
route 10.4.1.0 255.255.255.0

Then the server's routing table:
172.27.0.2 dev tun0  proto kernel  scope link  src 172.27.0.1
192.168.20.0/24 dev vmnet8  proto kernel  scope link  src 192.168.20.1
10.4.1.0/24 via 172.27.0.2 dev tun0
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.71
192.168.0.0/24 dev br1  proto kernel  scope link  src 192.168.0.72
192.168.30.0/24 dev vmnet1  proto kernel  scope link  src 192.168.30.1
172.27.0.0/16 via 172.27.0.2 dev tun0
default via 192.168.0.1 dev eth0

VPN clients and the VPN server communicate without any problem.  I can
see the routes for the tun interface on the server - everything looks
right to me.

On a server-side LAN client, I add a route to the VPN.  For a Windows
client, I would execute:
route add 172.27.0.0 mask 255.255.0.0 192.168.0.71

And then test the connection.  I can ping the VPN server at 172.27.0.1
without problem.  But I can't ping the VPN clients.  Is an iptables rule
required for this step?

Daniel
-----------------------

Daniel,

I'm a little confused with your setup...

The server directive should be a non-routable, shouldn't it?

i.e., I have

server 10.0.2.0 255.255.255.0
dev tun
topology subnet

I don't worry about local setting, it's optional and will bind to all the
internal ethernet cards on the network.

by setting the topology to subnet and using the ifconfig-pool-persist
directive, the other ends get a consistent address within the 10.0.2.0/24
network. In ther words, the server end of the tunnel gets 10.0.2.1 and the
client consistently gets 10.0.2.4 (in my case).

I then push, from the server, the internal routes of the server, i.e.,
push route "192.168.xx1.0 255.255.255.0"
push route "192.168.xx2.0 255.255.255.0"
etc (I'm pushing 4 routes)

and added

client-to-client

and

persist-key
persist-tun

My client end is

route 192.168.x10.0 255.255.255.0

the above statement being part of server config, I just needed to add the
route manually to the client's internal network.

Note that my client is actually a single server with workstations behind it
getting their dhcp addresses from the local server, 192.168.x10.1, I am not
serving dhcp from the server.

The client "server" gets it's server routes pushed to it and this is
transparent to all the workstations on the client end. I add no routes to
the client's workstations since they only have one route now. The client is
the only gateway for the client's lan.

So, my server tun0 is 10.0.2.1
my client "server" tun0 is 10.0.2.4

The OpenVPN client end is setup by the OpenVPN server, but at the server I
had to add the route to the client, i.e, #route add -net 192.168.x10.0/24 gw
10.0.2.4 (the client end of the tunnel)

Setting the topology to subnet simplified this greatly, I'm only dealing
with two addresses, 10.0.2.1 and 10.0.2.4, either end of the tunnel. The
server needs the addition of the route to the client's network, the client
gets the route from the server ( as I mentioned, I have linux boxes at
either end, so I just popped the route add -net statemet into the openvpn
startup script, as well as the proxy_arp statements, echo 1 > /proc/sys/net
etc).

As for the firewalls, the server has a static ip, the client is on a cable
network, so on the server I have

iptables -I INPUT -i eth0 -p udp -s my.dyndns.addr --sport 1194 --dport 1194
-j ACCEPT
iptables -I OUTPUT -o eth0 -p udp -s my.dyndns.addr --sport 1194 --dport
1194 -j ACCEPT
iptables -I FORWARD -i eth0 -p udp -s my.dyndns.addr --sport 1194 --dport
1194 -j ACCEPT

(This last one probably isn't needed)

iptables -I INPUT -i tun+ -s 192.168.x10.0/24 -d 192.168.xx1.0/24 -j ACCEPT
iptables -I OUTPUT -o tun+ -s 192.168.xx1.0/24 -d 192.168.10.0/24 -j ACCEPT
iptables -I FORWARD -i tun+ -s 192.168.x10.0/24 -d 192.168.xx1.0/24 -j ACCEPT
iptables -I FORWARD -o tun+ -s 192.168.xx1.0/24 -d 192.168.x10.0/24 -j ACCEPT

iptables -I INPUT -i tun+ -s 10.0.2.4 -d 192.168.xx1.0/24 -j ACCEPT
iptables -I OUTPUT -o tun+ -s 10.0.2.4 -d 192.168.x10.0/24 -j ACCEPT
iptables -I FORWARD -i tun+ -s 10.0.2.4 -d 192.168.xx1.0/24 -j ACCEPT
iptables -I FORWARD -o tun+ -s 10.0.2.4 -d 192.168.x10.0/24 -j ACCEPT

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


Now, for those others who are reading this, I know it's overkill, but I have
not finished cleaning this up and getting rid of the unnecesary stuff. I
suspect that the -s 10. network stuff really isn't needed, but I don't think
it can hurt right now. I was strugging with the server side of the firewall
and the middle eight statements seemed to help.

On the client side all I have is the initial three iptables statements with
the server's static ip address as well as the last 3 statements.

Hopefully that will get you closer, Daniel, and hopefully it's not too
disjointed an explanation... it's getting late for a Sunday and I'm hitting
the rack.

The default client and server .conf files and their in-line comments helped
me a lot, and I really appreciated the fact that they were part of the
distribution. I had been struggling with openswan/ipsec and intermittent
connectivity for weeks. OpenVPN is far easier to set up and it consistently
works well.

Regards,

John C.



____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users