OK, some progress but a question - when running a client (laptop,etc) behind an OpenVPN "client" box, is it normal to see the private IP from the laptop on the server side? The reason I ask is that part of what was wrong with my setup involved firewall (Fortinet, not IPTables) rules. I have a number of rules that affect the VPN systems; the rules permit or deny traffic from the VPN virtual adapters to various resources on the pushed networks. In order to make my current project's config work -
laptop --> VPN client -->Internet --> corp firewall --> VPN server -->pushed routes
- I had to add not only a static route for the client subnet but also had to add the subnet to the access group that includes the VPN virtual adapters. For example, I have an access group called "VPN_vServers" that includes the virtual subnets
(two daemons running, one for UDP and one for TCP). In order to gain access from the client network, I had to add the physical subnet,
, to this access group. As soon as I did this, I could access resources on the pushed subnets though I'm still having trouble the other way (will deal w/ that on Monday).
In doing a tail on my firewall's syslog, I see the private IP from my client-side laptop and not the virtual IP (10.8.0.x) from the VPN which is what I am used to seeing with my road-warrior setup - is this normal?
Anyway, making progress - thanks again for everyone's help thus far..James, you are right, TCPDump rocks!! Any thoughts or insight on the above would be appreciated; I just want to make sure that it is working correctly.
On 8/10/07, James Miller <jimm@xxxxxxxxxxxxxxx> wrote:
Sorry for the top post, I'm using Outlook -- but at least I'm sending as
I have a few sites who connect back to us with a similar configuration.
Here's two tenant I've learned:
1. If the VPN is setup right, then it's either a routing or firewall issue
2. tcpdump IS YOUR FRIEND! =)
I have a few questions and thoughts:
1. Is the VPN server also your firewall? If not you'll need to manually
setup routes on the firewall/gw to point traffic for 192.168.1.100 back to
the VPN server (same for the client side?
2. What does 'route -n' show on the server side when the VPN is up and not
up? You should see a route for 192.168.100.0/24 through a 10.9.0.X IP addr
(tap adapter). How about the client side? It should have routes for
192.168.2.0/24 and 192.168.6.0/24 pointing to the 10.9,.0.X IP addr of it's
3. Check that you're forwarding IP traffic and check your firewall rules.
I've been burned by not setting my rules correctly more than once.
4. As a side note, over time there will be a need to revoke/retire client
side (and server side for that matter) certificates. When you get more
comfortable with OpenVPN administration you WILL want to setup a process for
certificate revocation and updating your crl.pem and other assundry ssl
Config file questions and suggestions:
Since you're setting up several remote offices, I would suggest the
following to help in the troubleshooting process:
1. I don't see where you're specifying which IP address to listen on. It
IS an optional parameter, but it's good practice to include it in your
2. I'm not using the 'ifconfig-pool-persist ipp.txt' option in my server
config files. And to be honest I'm sure what it buys you.
3. Have separate log for each office:
4. It seems odd to be using TCP https:443 as your port, you'll get better
performance out of UDP and I'd suggest using something in the 5000 range.
But I'm sure you have your reasons.
5. Define a unique management port for each office VPN as well.
management localhost 7510
6. What is the contents of the file in the client-config-dir and what is it
a. I name mine for the CN= entry of /etc/ssl/index.txt for that
client. For example, if my CN is 'CN=Office1 Gateway, in my ccd directory I
have a file named Office1Gateway
b. in each file I define two things, the ifconfig-push variable and
the iroute variable. In your case it should look something like this:
ifconfig-push 10.9.0.5 10.9.0.6 #This assigns a set IP
based on the CN to your client side.
iroute 192.168.100.0 255.255.255.0 #You're saying this is
the IP space of the remote office
Anyway I hope this help.
openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Iad Scoot
Sent: Thursday, August 09, 2007 6:30 PM
Subject: Re: [Openvpn-users] site to site vpn - routing issues
Forgot to mention that I already have ip forwarding enabled on the
On 8/9/07, Iad Scoot <
Hi, sorry for the long post but I need advice - also sorry
if this got double-posted, I'm having some address book issues...
Trying to set up a site-to-site vpn between 2 openvpn
(CentOS 4.5 w/ openvpn 2.0.9) systems. Site 1 (corp office) has its openvpn
system configured as "server". Fortinet firewall sitting in front of the
corp office lan; vpn server in DMZ and static route set for incoming vpn
traffic to go to the vpn box. Site 2 (remote office) has vpn box configured
as "client" for routing traffic from several laptops at the remote office to
the corp office. Second Fortinet firewall sitting in front of the remote
office lan; laptops connected to the internal interface (GREEN segment) and
vpn box connected to the DMZ. Static routes have been set on the firewall to
pass any traffic destined for the pushed remote subnets to the vpn box.
Using routing, TLS w/ certs, etc. I can establish a tunnel
but cannot access resources on the pushed subnets. On the remote office
side, I can ping from the vpn box to the subnet at the corp office that the
vpn server is on but not any of the other subnets that are "pushed" to the
client vpn box. Here's the server config (corp office):
10.9.0.0 <http://10.9.0.0/> 255.255.255.0
push "route 192.168.2.0 <http://192.168.2.0/> 255.255.255.0
push "route 192.168.6.0 <http://192.168.6.0/> 255.255.255.0
route 192.168.100.0 <
keepalive 10 120
tls-auth hmac.key 0
cipher AES-256-CBC # AES
The server config includes a file within the "ccd" directory
with the appropriate "iroute" command. Here is the client config:
remote my_external_ip 443
tls-auth hmac.key 1
Any thoughts? Could really use some help on this - need to
do a couple of remote offices in this manner.