[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 20:46:07 -0400 (EDT)
  • Importance: Normal

Date: Sat, 08 Sep 2007 15:49:40 -0700
From: "Daniel L. Miller" <dmiller@xxxxxxxxx>
Subject: Re: [Openvpn-users] Possible routing problem
To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Message-ID: <46E32704.40207@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Daniel L. Miller wrote:
> I don't know if this was the CORRECT solution, but adding an iptables
> source-NAT on the VPN server, directing my LAN-client traffic intended
> for the VPN to go through the TUN interface seems to work.
>
Well, I though I had it, but I guess not.

To review - I'm trying to access a TUN/udp/routed vpn from within the
vpn-server's LAN.  vpn communication between clients and (linux) server
seems fine.

Is LAN to VPN client communication done purely through routing tables?
Or are re-direct rules such as iptables required?

Daniel

-----------------

Daniel,

I recently set up openvpn between two lans and wanted clients on both sides
to have full access to either side. I used the tun setup, server - client
with persistent key and tun settings and topology subnet. Both the client
and server are linux boxes, each have windows XP boxes behind them as well
as two internal servers on the server side. I had to add routes to the
openvpn server on the two internal servers and add a couple of iptable
directives to get it all to work smoothly, including the samba servers on
either side.

Additionally I also add proxy_arp directives
(/proc/sys/net/conf/tun0/proxy_arp and /proc/sys/net/conf/eth1/proxy_arp
were changed to ones - the eth1 interface is the internal eth that openvpn
listens on) The proxy_arp directive cleared some issues both with samba and
asterisk voip on both networks. Now internal clients on both side can
successfully arping clients on the other side.

The server side also needed an additional route - the client side internal
is 192.168.xxx.0/24 and the route added on the server is -net
192.168.xxx.0/24 gw client side tun0 address. The client side needed no
additional routing to the 4 internal lans on the server side since they were
pushed from the server.

for iptables on both sides I opened the outside eth to port 1194, both
inputs and outputs, to the outside address of the other end, and also I
added input, output, and forward for tun+.

It took a few days to figure this all out, but it all seems to work as
smooth as pie now. The first critical steps for me were switching to subnet
topology and adding the route from the server to the client side tunnel.
After that things just sorta fell into place.

I hope the above isn't too confusing :-)

Regards,

John Cusick







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