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

Re: [Openvpn-users] Remote location routing/firewall problem

  • Subject: Re: [Openvpn-users] Remote location routing/firewall problem
  • From: john@xxxxxxxxx
  • Date: Tue, 18 Sep 2007 07:47:24 -0400 (EDT)
  • Importance: Normal

Date: Mon, 17 Sep 2007 17:01:47 -0400
From: Me <gm4rtin@xxxxxxxxx>
>Subject: [Openvpn-users] Remote location routing/firewall problem
>To: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
>        <43806ba60709171401s1334bb6fx662f154b59cc4460@xxxxxxxxxxxxxx>
>Content-Type: text/plain; charset=ISO-8859-1
>Server A is located in the DMZ at Location 1 (provides access to one
>subnet a firewall)
>Server B is located at Location 2
>Loc2network---ServerB ===Internet===ServerA---Firewall---Router--->Loc1network
>Both servers are running Openvpn 2.1 on linux with both a server and
>client config.  Location2's network can access resources on ServerA as
>well as the Loc1network.  The problem is that hosts on Loc1network can
>not access ServerB or Loc2network.  A traceroute from Loc1network to
>ServerB dies at ServerA.  Any ideas?

Firewalls and Routing?

I had a similar problem when I first set everything up - my setup is similar
to yours.

With a lot of tcpdum on both sides I figured out that internal hosts on the
VPN Server side needed an "route add" statement to the VPN client side. The
VPN server itself also needed a "route add" statement.

I also used the network topology statemet tosetup a single tun0 address on
both sides which made it far easier for me to wrap my brain around, if
nothing else.

For example, with a server tun of and a client tun of
and a server net of and a client net of

I had to add a "route add gw" on the VPN server
side in order to reach all the clients on the VPN client side.

With the "push" statment on the VPN Server side, route statements on the VPN
client side weren't necesary. Initially pings went out from a VPN internal
client host to the VPN Server and stopped dead in their tracks. The VPN
Server could return to the VPN Client, but was clueless about other hosts on
the client side.

Also, clients on the VPN Server side needed "route add
gw192.168.1.1" (my internal Server side gateway)

After that it was just a matter of tweaking some iptable rules, just adding
the recommended "Accept tun+" statements didn't quite do it.

I know this isn't as clear as it could be. It helps to have ssh access from
a client on both sides to the other network, which I had. I was able to
drill down with tcpdump from one station tied to both sides of the network
and root out all the bottlenecks and show stoppers.


John C.

Openvpn-users mailing list