Networking Forums

Networking Forums > Computer Networking > Linux Networking > OpenVPN configuration problem

Reply
Thread Tools Display Modes

OpenVPN configuration problem

 
 
Franck
Guest
Posts: n/a

 
      06-14-2005, 06:02 PM
Hello,

I'm trying to setup a VPN between 2 Linux hosts (remotely connected from
eachother through internet) using openVPN 2.0.1.

I succeed establishing the VPN between the both hosts in both direction
(Host 1 being server and Host2 being client, or Host1 being client and Host2
being server). But i have a routing problem outside of Linux hosts as no
ping is possible except the ping of the virtual network addresses created
through the VPN and the ping of LAN IP address from the client to the
server. a Ping from server to client on LAN IP address is also not working
and no other hosts on each LAN can't ping other side of the VPN.

Here is the detailled network configuration :

Host1 (Linux FC3) : 192.168.1.1 (net : 192.168.1.0/24). this host has a
single NIC interface.
He is located on a LAN where there is a ADSL/Router located in
192.168.1.139.
Several others computer are also on this network.

Host2 (Linux FC3) : 192.168.0.1 (net : 192.168.0.0/24). This host have also
a single NIC interface.
He is on a LAN where there is a ADSL/Router located in 192.168.0.138.

Both LAN are connecting to Internet via the ADSL router and port forwarding
on 1194 has been enabled on both. Firewall is on on the routers but rules
have been temporarily suppressed to be sure there's no firewall problem.
Firewall rules on the linux servers are also suppressed temporarily.

When the VPN is established, a VPN network is created using 10.8.0.0
network.
Server is taking 10.8.0.1 (IP)/10.8.0.2 (P-t-P)
Client is taking 10.8.0.6(IP)/10/8/0/5(P-t-P)


******* Routes established after VPN connection :
*** Server :
10.8.0.2 * 255.255.255.255 UH 0 0
0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0
0 tun0
192.168.1.0 * 255.255.255.0 U 0 0
0 eth0
192.168.0.0 10.8.0.2 255.255.255.0 UG 0 0
0 tun0
169.254.0.0 * 255.255.0.0 U 0 0
0 eth0
default 192.168.1.139 0.0.0.0 UG 0 0
0 eth0

*** Client :
10.8.0.5 * 255.255.255.255 UH 0 0
0 tun0
10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0
0 tun0
192.168.1.0 10.8.0.5 255.255.255.0 UG 0 0
0 tun0
192.168.0.0 * 255.255.255.0 U 0 0
0 eth0
169.254.0.0 * 255.255.0.0 U 0 0
0 eth0
default 192.168.0.138 0.0.0.0 UG 0 0
0 eth0


******* TUN interfaces created are :
*** Server :
tun0 Lien encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.0.1 P-t-P:10.8.0.2 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

*** Client :
tun0 Lien encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet adr:10.8.0.6 P-t-P:10.8.0.5 Masque:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

******* Config Files :
*** Server :
port 1194
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/host1.crt
key /etc/openvpn/keys/host1.key
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
client-config-dir /etc/openvpn
route 192.168.0.0 255.255.255.0
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

client-specific file on server contain this single line : iroute
"192.168.0.1 255.255.255.0"


*** Client :
client
dev tun
proto udp
remote fcaconde.dyndns.org 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/optiplex2-client.crt
key /etc/openvpn/keys/optiplex2-client.key
ns-cert-type server
comp-lzo
verb 4

*** TCP forwarding has been enabled on both hosts using : echo 1 >
/proc/sys/net/ipv4/ip_forward

Based on that config, here is what happend :

From server :
1- PING 10.8.0.6 is OK
2- PING 10.8.0.5 is NOK
3- PING 192.168.0.1 is OK only after creation of client-specific file on
server
4- PING 192.168.0.X is NOK. using a "tcpdump -i tun0" on the client shows
that no trafic is coming from server !!!

From client :
1- PING 10.8.0.1 is OK
2- PING 10.8.0.2 is NOK
3- PING 192.168.1.1 is OK.
4- PING 192.168.1.X is NOK. using a "tcpdump -i tun0" on the server shows
trafic coming from client, so probably a problem of setting up return routes
on other hosts on the server LAN.

Could someone explains me what I do wrong ?
Is there other hidden option somewhere ?
Why is there no toher trafic possible than the one between Linux hosts ?
Is it coming from the fact that our servers are equipped with a single NIC
interface ?

Thanks for your help.
Franck.





 
Reply With Quote
 
 
 
 
Steve Horsley
Guest
Posts: n/a

 
      06-14-2005, 07:07 PM
Franck wrote:
> Hello,
>
> I'm trying to setup a VPN between 2 Linux hosts (remotely connected from
> eachother through internet) using openVPN 2.0.1.
>
> I succeed establishing the VPN between the both hosts in both direction
> (Host 1 being server and Host2 being client, or Host1 being client and Host2
> being server). But i have a routing problem outside of Linux hosts as no
> ping is possible except the ping of the virtual network addresses created
> through the VPN and the ping of LAN IP address from the client to the
> server. a Ping from server to client on LAN IP address is also not working
> and no other hosts on each LAN can't ping other side of the VPN.
>
> Here is the detailled network configuration :
>
> Host1 (Linux FC3) : 192.168.1.1 (net : 192.168.1.0/24). this host has a
> single NIC interface.
> He is located on a LAN where there is a ADSL/Router located in
> 192.168.1.139.
> Several others computer are also on this network.
>
> Host2 (Linux FC3) : 192.168.0.1 (net : 192.168.0.0/24). This host have also
> a single NIC interface.
> He is on a LAN where there is a ADSL/Router located in 192.168.0.138.
>
> Both LAN are connecting to Internet via the ADSL router and port forwarding
> on 1194 has been enabled on both. Firewall is on on the routers but rules
> have been temporarily suppressed to be sure there's no firewall problem.
> Firewall rules on the linux servers are also suppressed temporarily.
>
> When the VPN is established, a VPN network is created using 10.8.0.0
> network.
> Server is taking 10.8.0.1 (IP)/10.8.0.2 (P-t-P)
> Client is taking 10.8.0.6(IP)/10/8/0/5(P-t-P)
>
>
> ******* Routes established after VPN connection :
> *** Server :
> 10.8.0.2 * 255.255.255.255 UH 0 0
> 0 tun0
> 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0
> 0 tun0
> 192.168.1.0 * 255.255.255.0 U 0 0
> 0 eth0
> 192.168.0.0 10.8.0.2 255.255.255.0 UG 0 0
> 0 tun0
> 169.254.0.0 * 255.255.0.0 U 0 0
> 0 eth0
> default 192.168.1.139 0.0.0.0 UG 0 0
> 0 eth0
>
> *** Client :
> 10.8.0.5 * 255.255.255.255 UH 0 0
> 0 tun0
> 10.8.0.0 10.8.0.5 255.255.255.0 UG 0 0
> 0 tun0
> 192.168.1.0 10.8.0.5 255.255.255.0 UG 0 0
> 0 tun0
> 192.168.0.0 * 255.255.255.0 U 0 0
> 0 eth0
> 169.254.0.0 * 255.255.0.0 U 0 0
> 0 eth0
> default 192.168.0.138 0.0.0.0 UG 0 0
> 0 eth0
>
>
> ******* TUN interfaces created are :
> *** Server :
> tun0 Lien encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> inet adr:10.8.0.1 P-t-P:10.8.0.2 Masque:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
>
> *** Client :
> tun0 Lien encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> inet adr:10.8.0.6 P-t-P:10.8.0.5 Masque:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
>
> ******* Config Files :
> *** Server :
> port 1194
> proto udp
> dev tun
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/host1.crt
> key /etc/openvpn/keys/host1.key
> dh /etc/openvpn/keys/dh1024.pem
> server 10.8.0.0 255.255.255.0
> ifconfig-pool-persist ipp.txt
> push "route 192.168.1.0 255.255.255.0"
> push "route 10.8.0.0 255.255.255.0"
> client-config-dir /etc/openvpn
> route 192.168.0.0 255.255.255.0
> client-to-client
> keepalive 10 120
> comp-lzo
> user nobody
> group nobody
> persist-key
> persist-tun
> status openvpn-status.log
> verb 3
>
> client-specific file on server contain this single line : iroute
> "192.168.0.1 255.255.255.0"
>
>
> *** Client :
> client
> dev tun
> proto udp
> remote fcaconde.dyndns.org 1194
> resolv-retry infinite
> nobind
> user nobody
> group nobody
> persist-key
> persist-tun
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/optiplex2-client.crt
> key /etc/openvpn/keys/optiplex2-client.key
> ns-cert-type server
> comp-lzo
> verb 4
>
> *** TCP forwarding has been enabled on both hosts using : echo 1 >
> /proc/sys/net/ipv4/ip_forward
>
> Based on that config, here is what happend :
>
> From server :
> 1- PING 10.8.0.6 is OK
> 2- PING 10.8.0.5 is NOK
> 3- PING 192.168.0.1 is OK only after creation of client-specific file on
> server
> 4- PING 192.168.0.X is NOK. using a "tcpdump -i tun0" on the client shows
> that no trafic is coming from server !!!
>
> From client :
> 1- PING 10.8.0.1 is OK
> 2- PING 10.8.0.2 is NOK
> 3- PING 192.168.1.1 is OK.
> 4- PING 192.168.1.X is NOK. using a "tcpdump -i tun0" on the server shows
> trafic coming from client, so probably a problem of setting up return routes
> on other hosts on the server LAN.
>
> Could someone explains me what I do wrong ?
> Is there other hidden option somewhere ?
> Why is there no toher trafic possible than the one between Linux hosts ?
> Is it coming from the fact that our servers are equipped with a single NIC
> interface ?
>
> Thanks for your help.
> Franck.
>
>
>
>
>


The routes you posted look OK - my first thought was that maybe
you weren't pushing the extra routes over the VPN. But it occurs
to me that the other devices that you are trying to ping may not
know the correct route to repy over. e.g.:
If you ping 192.168.1.2 (on the server's LAN) from the client,
then the ping source address will be 10.8.0.6. Does the device
192.168.1.2 know of a route back to 10.8.0.6 via 10.8.0.1? Either
a specific route or a default route will do. I am guessing that
this reply route is missing.

Either that, or the server is not doing IP forwarding. From the
install notes:
* Linux 2.4 or higher (with integrated TUN/TAP driver):

(1) make device node: mknod /dev/net/tun c 10 200
(2a) add to /etc/modules.conf: alias char-major-10-200 tun
(2b) load driver: modprobe tun
(3) enable routing: echo 1 > /proc/sys/net/ipv4/ip_forward

Steve
 
Reply With Quote
 
Franck
Guest
Posts: n/a

 
      06-15-2005, 10:10 AM
Hi,

thanks for your answer.

I've progressed a bit based on your suggestion, but there are still some
problems.

Here is what I did :
- I configured tun device driver as mentionned.
- I setup proper routes in others hosts of each LAN. I added 2 each time :
*** On server's LAN hosts :
route to 10.8.0.0 via 192.168.1.1
route to 192.168.0.0 via 192.168.1.1

*** On client's LAN hosts :
route to 10.8.0.0 via 192.168.0.1
route to 192.168.1.0 via 192.168.0.1

Now,
- when i ping from the client a host on server's LAN, it works.
- when i ping from the server a host on client's LAN, it works only if add
the host in the client config file on server. Which is very strange for me
!!!

BUT :
- if i ping from a host on the client's LAN to a host on server's LAN, it
doesn't work !
- if i ping from a host on the server's LAN to a host on client's LAN, it
doesn't work !

tcpdump -i tun0 on each machine doesn't show any trafic in this case. So it
means nothing is send via the VPN tunnel when the packet is coming from the
LAN.

I've checked that ip_forward is enabled on each Linux box.

Kernel parameter of TUN0 device are as follow on each Linux box :
net.ipv4.conf.tun0.disable_policy = 0
net.ipv4.conf.tun0.disable_xfrm = 0
net.ipv4.conf.tun0.arp_ignore = 0
net.ipv4.conf.tun0.arp_announce = 0
net.ipv4.conf.tun0.arp_filter = 0
net.ipv4.conf.tun0.tag = 0
net.ipv4.conf.tun0.log_martians = 0
net.ipv4.conf.tun0.bootp_relay = 0
net.ipv4.conf.tun0.medium_id = 0
net.ipv4.conf.tun0.proxy_arp = 0
net.ipv4.conf.tun0.accept_source_route = 0
net.ipv4.conf.tun0.send_redirects = 1
net.ipv4.conf.tun0.rp_filter = 1
net.ipv4.conf.tun0.shared_media = 1
net.ipv4.conf.tun0.secure_redirects = 1
net.ipv4.conf.tun0.accept_redirects = 1
net.ipv4.conf.tun0.mc_forwarding = 0
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.neigh.tun0.locktime = 99
net.ipv4.neigh.tun0.proxy_delay = 79
net.ipv4.neigh.tun0.anycast_delay = 99
net.ipv4.neigh.tun0.proxy_qlen = 64
net.ipv4.neigh.tun0.unres_qlen = 3
net.ipv4.neigh.tun0.gc_stale_time = 60
net.ipv4.neigh.tun0.delay_first_probe_time = 5
net.ipv4.neigh.tun0.base_reachable_time = 30
net.ipv4.neigh.tun0.retrans_time = 99
net.ipv4.neigh.tun0.app_solicit = 0
net.ipv4.neigh.tun0.ucast_solicit = 3
net.ipv4.neigh.tun0.mcast_solicit = 3

It seems the IP forwarding from LAN to LAN isn't working, even if the routes
are correctly setup while doing the "route" command.

Any other suggestion.
Franck.


"Steve Horsley" <(E-Mail Removed)> a écrit dans le message de news:
d8n9i6$6o1$(E-Mail Removed)...
> The routes you posted look OK - my first thought was that maybe you
> weren't pushing the extra routes over the VPN. But it occurs to me that
> the other devices that you are trying to ping may not know the correct
> route to repy over. e.g.:
> If you ping 192.168.1.2 (on the server's LAN) from the client, then the
> ping source address will be 10.8.0.6. Does the device 192.168.1.2 know of
> a route back to 10.8.0.6 via 10.8.0.1? Either a specific route or a
> default route will do. I am guessing that this reply route is missing.
>
> Either that, or the server is not doing IP forwarding. From the install
> notes:
> * Linux 2.4 or higher (with integrated TUN/TAP driver):
>
> (1) make device node: mknod /dev/net/tun c 10 200
> (2a) add to /etc/modules.conf: alias char-major-10-200 tun
> (2b) load driver: modprobe tun
> (3) enable routing: echo 1 > /proc/sys/net/ipv4/ip_forward
>
> Steve



 
Reply With Quote
 
Steve Horsley
Guest
Posts: n/a

 
      06-15-2005, 10:46 PM
Franck wrote:
> Hi,
>
> thanks for your answer.
>
> I've progressed a bit based on your suggestion, but there are still some
> problems.
>
> Here is what I did :
> - I configured tun device driver as mentionned.
> - I setup proper routes in others hosts of each LAN. I added 2 each time :
> *** On server's LAN hosts :
> route to 10.8.0.0 via 192.168.1.1
> route to 192.168.0.0 via 192.168.1.1
>
> *** On client's LAN hosts :
> route to 10.8.0.0 via 192.168.0.1
> route to 192.168.1.0 via 192.168.0.1
>


Looks good...


> Now,
> - when i ping from the client a host on server's LAN, it works.
> - when i ping from the server a host on client's LAN, it works only if add
> the host in the client config file on server. Which is very strange for me
> !!!


Ah! I think I know why this is. There is a virtual router sitting
in the middle of the VPN, with the two IP addreses 10.8.0.2 and
10.8.0.6. Maybe the client config is pushng routes into this
virtual router, telling it which of many possible clients the
192.168.1.x network can be reached on. So I guess the client
config should specify the client network - 192.168.1.0 255.255.255.0.

>
> BUT :
> - if i ping from a host on the client's LAN to a host on server's LAN, it
> doesn't work !
> - if i ping from a host on the server's LAN to a host on client's LAN, it
> doesn't work !
>
> tcpdump -i tun0 on each machine doesn't show any trafic in this case. So it
> means nothing is send via the VPN tunnel when the packet is coming from the
> LAN.
>
> I've checked that ip_forward is enabled on each Linux box.


This I don't understand. We know that forwarding is enabled
because the client can ping the server LAN (proves the server can
forward) and the server can ping the client LAN (proves the
client can forward). It really smells like either missing routes
or firewall entries to me. I would probably use tcpdump to prove
that packets are (not) traversong every interface on every step
of this journey. Prove they arrive on eth0, prove they exit on
tun0 etc. Try to find exactly where they are going missing.

Steve

 
Reply With Quote
 
Franck
Guest
Posts: n/a

 
      06-17-2005, 04:11 PM
Hi,

Now everything works.

What have been done.
- Reinstallation of both Linux boxes into FC4.
- Edit of /etc/sysctl.conf file to force ip_forwading + reboot
- Reconfig of vpn server and client : keys + client and server config file.
- Configure routes as mentionned previously on each linux box and each LAN's
hosts.

The only thing is to add to a client config file on the server the 254 IP
addresses possible with iroute keyword, ie :

iroute "192.168.0.1 255.255.255.0"
iroute "192.168.0.2 255.255.255.0"
iroute "192.168.0.3 255.255.255.0"
iroute "192.168.0.4 255.255.255.0"
....
iroute "192.168.0.254 255.255.255.0"

Now all the systems can ping each others.

I don't really know what was wrong with FC3 configuration but now in FC4 ,
everything works. I don't think it was a FC3 problem. Could be several
configuration problem at the same time.

A big thank you for all your support.

Bye.
Franck.

"Steve Horsley" <(E-Mail Removed)> a écrit dans le message de news:
d8qekd$73n$(E-Mail Removed)...
> Franck wrote:
>> Hi,
>>
>> thanks for your answer.
>>
>> I've progressed a bit based on your suggestion, but there are still some
>> problems.
>>
>> Here is what I did :
>> - I configured tun device driver as mentionned.
>> - I setup proper routes in others hosts of each LAN. I added 2 each time
>> :
>> *** On server's LAN hosts :
>> route to 10.8.0.0 via 192.168.1.1
>> route to 192.168.0.0 via 192.168.1.1
>>
>> *** On client's LAN hosts :
>> route to 10.8.0.0 via 192.168.0.1
>> route to 192.168.1.0 via 192.168.0.1
>>

>
> Looks good...
>
>
>> Now,
>> - when i ping from the client a host on server's LAN, it works.
>> - when i ping from the server a host on client's LAN, it works only if
>> add the host in the client config file on server. Which is very strange
>> for me !!!

>
> Ah! I think I know why this is. There is a virtual router sitting in the
> middle of the VPN, with the two IP addreses 10.8.0.2 and 10.8.0.6. Maybe
> the client config is pushng routes into this virtual router, telling it
> which of many possible clients the 192.168.1.x network can be reached on.
> So I guess the client config should specify the client network -
> 192.168.1.0 255.255.255.0.
>
>>
>> BUT :
>> - if i ping from a host on the client's LAN to a host on server's LAN, it
>> doesn't work !
>> - if i ping from a host on the server's LAN to a host on client's LAN, it
>> doesn't work !
>>
>> tcpdump -i tun0 on each machine doesn't show any trafic in this case. So
>> it means nothing is send via the VPN tunnel when the packet is coming
>> from the LAN.
>>
>> I've checked that ip_forward is enabled on each Linux box.

>
> This I don't understand. We know that forwarding is enabled because the
> client can ping the server LAN (proves the server can forward) and the
> server can ping the client LAN (proves the client can forward). It really
> smells like either missing routes or firewall entries to me. I would
> probably use tcpdump to prove that packets are (not) traversong every
> interface on every step of this journey. Prove they arrive on eth0, prove
> they exit on tun0 etc. Try to find exactly where they are going missing.
>
> Steve
>



 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
openvpn problem Marco Linux Networking 2 11-21-2008 05:35 AM
Problem with Openvpn Wojtek_news Linux Networking 1 09-17-2007 01:02 PM
Problem with OpenVPN John Oliver Linux Networking 4 10-13-2006 08:00 PM
OpenVPN UDP Problem Florian Linux Networking 8 07-28-2005 09:06 AM
OpenVPN/VPN routing problem stefan Linux Networking 0 12-16-2003 05:30 PM



1 2 3 4 5 6 7 8 9 10 11