LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 08-03-2009, 04:13 AM   #1
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Rep: Reputation: 17
OpenVPN - tun - tap - tunnels


Hi everyone,

Thank you for reading my post.

My question is linked to OpenVPN but is, in fact, a more general question
about network interfaces and virtual interfaces.

In the OpenVPN "server.conf" file, one can find the following comment:

Code:
# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
# Use "dev tap0" if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
I have two machines A and B (Unix).
A is in the subnet 192.168.0.0/24.
B is in the subnet 192.168.2.0/24.
Each subnet has its own router with two interfaces:
- one private interface (192.168.x.1 where x belongs to {0, 2}),
- one public interface (with public IPs W1.X1.Y1.Z1 and W2.X2.Y2.Z2 respectively).
The routers are NAT (Network Address Translation) gateways.
The tunnels I want to create are between A and B.
The Ethernet tunnel is at the OSI physical layer.
The IP tunnel is at the OSI network layer.

Can you tell me how to create such tunnels properly?
I mean: I don't know how to create them, destroy them, supervise them, examine them.
Which are the configuration files, the log files, the key commands which have to be known to handle that problem properly?

Thank you for your help ,
all the best,
--
Léa

Last edited by leamassiot; 08-03-2009 at 09:08 AM.
 
Old 08-03-2009, 01:16 PM   #2
mjsurette
Member
 
Registered: May 2005
Distribution: spiral, fedora
Posts: 65

Rep: Reputation: 18
I'm not familiar with OpenVPN but I am familiar with vpns in general.

The first job is to verify that both machines see each other. More specifically can A ping B and B ping A? If you can't, you have a routing issue and nothing you do with OpenVPN will ever have a chance of working.

The second step is to verify that neither machine has a firewall blocking the necessary ports. Again no chance for the poor tunnel if there's a firewall in the way.

You would likely want a routed connection which would indicate a tun device.

Finally if you're still having problems repost with details on what you've tried and what error messages you're getting.

hth

Mike
 
Old 08-04-2009, 03:31 AM   #3
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
Thank you for your answer.

Quote:
The first job is to verify that both machines see each other.
More specifically can A ping B and B ping A?
That's right.
It is not yet working.

What I have done for the time being is the following:

On machine A (IP = 192.168.0.4 NETMASK = 255.255.255.0).

==(1) I edited first "/etc/network/interfaces" and added the following section:

Code:
auto tun0
iface tun0 inet static
	address 192.168.0.99
	netmask 255.255.255.0
	pointopoint W2.X2.Y2.Z2
Note that I chose the address 192.168.0.99 totally arbitrarily (though it was a free address).

==(2) I also edited "/etc/init.d/networking" and added the following instructions in the "start" section ("/etc/init.d/networking start"):

Code:
[...]
openvpn --mktun --dev tun0
[...]
if ifup -a; then
	route add -net 192.168.2.0 netmask 255.255.255.0 gw W2.X2.Y2.Z2 tun0
else
[...]
Note that, concerning the "openvpn" command I just wanted not to have that kind of message:
Code:
# ifup tun0
SIOCSIFADDR: No such device
tun0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
SIOCSIFDSTADDR: No such device
tun0: ERROR while getting interface flags: No such device
tun0: ERROR while getting interface flags: No such device
Failed to bring up tun0.
Maybe there exists a simpler, more basic way to avoid such an issue... ?

==(3) I rebooted the system and executed the following commands:

Code:
# ifconfig -a
eth0      Link encap:Ethernet  HWaddr <aa:bb:cc:dd:ee:ff>
          inet addr:192.168.0.4  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: <aa::bb:cc:dd:ee>/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9922 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11510 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1147330 (1.0 MiB)  TX bytes:1942208 (1.8 MiB)
          Interrupt:20 Base address:0xa400

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:560 (560.0 B)  TX bytes:560 (560.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.99  P-t-P:W2.X2.Y2.Z2  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:94 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     W2.X2.Y2.Z2     255.255.255.0   UG    0      0        0 tun0
W2.X2.Y2.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
I am not really happy with the route:
Code:
W2.X2.Y2.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
It has no meaning, no?

I am about to do approximately the same thing on machine B...

Please tell me if you think it is not the proper way to do things...

All the best,
--
Léa
 
Old 08-04-2009, 04:25 AM   #4
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
Hi again,

==(1) So now, on machine A, I have the following routes:

Note that I suppressed the following route:
Code:
<machine A># route del W2.X2.Y2.0 gw 0.0.0.0  tun0
Code:
<machine A># route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     W2.X2.Y2.Z2     255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
==(2) On machine B:

Code:
<machine B># route del W1.X1.Y1.0 gw 0.0.0.0  tun0
Code:
<machine B># route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     W1.X1.Y1.Z1     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0
On machine A (192.168.0.4) I can't ping machine B (192.168.2.4).
On machine B (192.168.2.4) I can't ping machine A (192.168.0.4).

All the best,
--
Léa
 
Old 08-04-2009, 02:52 PM   #5
mjsurette
Member
 
Registered: May 2005
Distribution: spiral, fedora
Posts: 65

Rep: Reputation: 18
Quote:
Originally Posted by leamassiot View Post
Hi again,

==(1) So now, on machine A, I have the following routes:

Note that I suppressed the following route:
Code:
<machine A># route del W2.X2.Y2.0 gw 0.0.0.0  tun0
Code:
<machine A># route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     W2.X2.Y2.Z2     255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
==(2) On machine B:

Code:
<machine B># route del W1.X1.Y1.0 gw 0.0.0.0  tun0
Code:
<machine B># route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     W1.X1.Y1.Z1     255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0
On machine A (192.168.0.4) I can't ping machine B (192.168.2.4).
On machine B (192.168.2.4) I can't ping machine A (192.168.0.4).

All the best,
--
Léa
Seems like you've made a bit of progress.

After a quick reading of the OpenVPN docs I've learned that the default port is udp/1194. Each of the routers must forward this traffic to the proper target machine.

You shouldn't delete those routes. They tell the network how to route vpn traffic. Also, the OpenVPN software should bring up the tun interfaces by itself. My impression is that once you tell it you want a tun interface, it takes care of all the necessary details.

I'm also left with the impression that the vpn network should have its own subnet. It's not clearly spelled out in any place that I can find, but there are things that point that way. This would make sense in that it would make OpenVPN the software emulation of two NICs connected to the same network, which is what it seems to be. Sometimes developers think something is so obvious they don't mention it. Try setting your vpn interfaces in a new subnet say 10.1.1.0/24. I suspect that this is the main source of your grief.

In my quick look at the docs I've noticed that you need a 'remote' directive in your configuration file. This tells the software where to send the encrypted traffic, so it must point to the external address of the alternate router.

You've probably already done the router forwarding and remote directive, but I thought I'd include them just in case you hadn't. Of course you have to remember, I've never used OpenVPN, these are just educated guesses and a second set of eyes on the documentation.

hth

Let me know how you make out.

Mike
 
Old 08-05-2009, 02:51 AM   #6
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
Hi,
Thank you for your answer.

Quote:
You shouldn't delete those routes.
The problem is that, if these routes are not deleted I can't access anymore the
remote machine B from A (via SSH) (fortunately I had someone on machine B who could delete
the route, otherwise I would have been stuck).

Quote:
Also, the OpenVPN software should bring up the tun interfaces by itself.
Yes, I think so too but my problem is that "tun0" interfaces do not exist on my systems and OpenVPN apparently
doesn't create them. It probably has to be done prior to running the OpenVPN daemon. I was asking how to do this.
Maybe, the command mentionned above (post #3: "openvpn --mktun --dev tun0") is ok.

CORRECTION:
I am sorry, "tun0" interface is automatically created when "/etc/init.d/openvpn" is started.
We may not execute the command "openvpn --mktun --dev tun0".

Quote:
I'm also left with the impression that the vpn network should have its own subnet. It's not clearly
spelled out in any place that I can find, but there are things that point that way. This would make
sense in that it would make OpenVPN the software emulation of two NICs connected to the same network,
which is what it seems to be. Sometimes developers think something is so obvious they don't mention it.
Try setting your vpn interfaces in a new subnet say 10.1.1.0/24. I suspect that this is the main source
of your grief.
Yes... really not obvious to me.

Quote:
You've probably already done the router forwarding and remote directive
Yes, I did it.
Thanks for reminding .

Regards,
--
Léa

Last edited by leamassiot; 08-05-2009 at 03:32 AM.
 
Old 08-05-2009, 03:27 AM   #7
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
In "/etc/openvpn/server.conf" there is the following directive:

Quote:
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0
I think this is what Mike alluded to in his post...
Well, my two subnets are 192.168.0.0/24 and 192.168.2.0/24
so, what is this 10.8.0.0/24 subnet?
Shouldn't I replace it with 192.168.2.0/24 (the OpenVPN server being
192.168.0.4)?

Thank you for your help,
all the best,
--
Léa

Last edited by leamassiot; 08-05-2009 at 03:34 AM.
 
Old 08-05-2009, 04:27 AM   #8
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
Hi again,

Here are the OpenVPN configuration files for the server and the client.
I changed the minimum number of things I could (see highlighted in bold).
I removed the comments to have a more compact view (maybe I shouldn't have, yout tell me).

(1) MACHINE A (OpenVPN server)
/etc/openvpn/server.conf

(I changed nothing in this file).

Code:
;local a.b.c.d
port 1194
proto udp
;dev tap
dev tun
;dev-node MyTap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
;server-bridge
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 208.67.222.222"
;push "dhcp-option DNS 208.67.220.220"
;client-to-client
;duplicate-cn
keepalive 10 120
;tls-auth ta.key 0 # This file is secret
;tls-auth ta.key 0 # This file is secret
;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
comp-lzo
;max-clients 100
;user nobody
;group nogroup
persist-key
persist-tun
status openvpn-status.log
;log         openvpn.log
;log-append  openvpn.log
verb 3
;mute 20
(2) MACHINE B (OpenVPN client)
/etc/openvpn/client.conf

Code:
client
;dev tap
dev tun
;dev-node MyTap
;proto tcp
proto udp
;remote my-server-1 1194
;remote my-server-2 1194
remote W1.X1.Y1.Z1 1194
;remote-random
resolv-retry infinite
nobind
;user nobody
;group nogroup
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
ca ca.crt
cert client.crt
key client.key
;ns-cert-type server
;tls-auth ta.key 1
;cipher x
comp-lzo
verb 3
;mute 20
I changed only one thing in that file (the "remote" directive).
"W1.X1.Y1.Z1" is the public IP of the router (192.168.0.1) which is on the same subnet as machine A (192.168.0.4) which is the OpenVPN server.

(3) I started the OpenVPN server (on machine A (192.168.0.4)):
Code:
192.168.0.4 # /etc/init.d/openvpn start
Code:
192.168.0.4 # ifconfig -a

eth0      Link encap:Ethernet  HWaddr AA:BB:CC:DD:EE:FF
          inet addr:192.168.0.4  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: AA::BB:CC:DD:EE/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3057 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2283 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:290014 (283.2 KiB)  TX bytes:307747 (300.5 KiB)
          Interrupt:20 Base address:0xa400

lo        [...]

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:504 (504.0 B)  TX bytes:1512 (1.4 KiB)
Code:
192.168.0.4 # route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         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.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
(4) I started this OpenVPN client (on machine B (192.168.2.4)):
Code:
192.168.2.4 # /etc/init.d/openvpn start
Code:
192.168.2.4 # ifconfig -a

eth0      Link encap:Ethernet  HWaddr AA:BB:CC:DD:EE:FF
          inet addr:192.168.2.4  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: AA::BB:CC:DD:EE/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4826 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4505 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:638864 (623.8 KiB)  TX bytes:742459 (725.0 KiB)
          Interrupt:201

lo        [...]

sit0      [...]

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:504 (504.0 b)  TX bytes:504 (504.0 b)
Code:
192.168.2.4 # route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0
(5) Now, on machine A (192.168.0.4):
  • I can ping 10.8.0.6.
  • But I cannot ping 192.168.2.4.

(6) And, on machine B (192.168.2.4):
  • I can ping 10.8.0.1.
  • But I cannot ping 192.168.0.4.

Do you have an idea about what has to be done?
Thank you for your help,
all the best,
--
Léa
 
Old 08-05-2009, 08:55 AM   #9
mjsurette
Member
 
Registered: May 2005
Distribution: spiral, fedora
Posts: 65

Rep: Reputation: 18
Quote:
Originally Posted by leamassiot View Post
Hi again,


(5) Now, on machine A (192.168.0.4):
  • I can ping 10.8.0.6.
  • But I cannot ping 192.168.2.4.

(6) And, on machine B (192.168.2.4):
  • I can ping 10.8.0.1.
  • But I cannot ping 192.168.0.4.

Do you have an idea about what has to be done?
Thank you for your help,
all the best,
--
Léa
Congratulations! You have a working VPN.

Imagine if both machines were in the same room, but on different networks and you wanted to connect them. You would add a NIC to each and connect them together. You couldn't have the new interfaces on either of the existing networks because that would confuse the routing. So you would create a new network, in this case the 10.8.0.0/24 network, and address both of the cards to be on that network. Once that was done, you could reach each machine from the other using that network.

If that's all you want to do, you're done. Just use the 10.8.0.x address for all your traffic. If you want to reach computers beyond the two connected ones or you just want to use the 192.168.x.x addresses, you have to set up the proper routing rules and enable IP forwarding, same as if you had two ethernet interfaces in each machine. See the OpenVPN FAQ on this.

I'm happy to see you've succeeded.

Mike
 
Old 08-05-2009, 10:58 AM   #10
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
Hi Mike, thank you for being happy .
I am not so happy because:

(1) I altered "/etc/openvpn/server.conf" on machine 192.168.0.4 in the following way, I added the two lines:
Code:
push "route 192.168.0.0 255.255.255.0"
route 192.168.2.0 255.255.255.0
(2) Now, on 192.168.0.4 the routing table is:
Code:
192.168.0.4 # route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.2.0     10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
(3) And, on machine 192.168.2.4, the routing table is:
Code:
192.168.2.4 # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.0.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0
(4) Now, 192.168.2.4 can ping 192.168.0.4 and, for example 192.168.0.202.

(5) But, but but... 192.168.0.4 cannot ping neither 192.168.2.4 nor, for example 192.168.2.14.
Why is that so???

Please help,
all the best,
--
Léa
 
Old 08-05-2009, 11:36 AM   #11
forubu
LQ Newbie
 
Registered: Jul 2009
Location: Trondheim, Norway
Distribution: Ubuntu
Posts: 28

Rep: Reputation: 16
Quote:
Originally Posted by leamassiot View Post
(5) But, but but... 192.168.0.4 cannot ping neither 192.168.2.4 nor, for example 192.168.2.14.
Why is that so???
I think perhaps the problem is within your client. Your VPN-client need to act as a gateway for it to send tcp-packets to other computers on your subnet.

Check in sysctl.conf and pay attention to the comments.
You might need to make a few changes there.

Code:
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.all.forwarding=1
and also these:
Code:
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.accept_source_route = 1
I can't say for sure that this is your problem but it's worth checking out.
I have done this once, a couple of years ago, but I forgot how it was done.
 
Old 08-05-2009, 12:44 PM   #12
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
Hi, thank you for your contribution.

I did what you suggested:
I added the four lines:
Code:
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.all.send_redirects=1
net.ipv4.conf.all.accept_source_route=1
to the OpenVPN "/etc/sysctl.conf" client...

but unfortunetely the situation remains the same...

Any other idea?
All the best,
--
Léa
 
Old 08-05-2009, 01:05 PM   #13
mjsurette
Member
 
Registered: May 2005
Distribution: spiral, fedora
Posts: 65

Rep: Reputation: 18
Quote:
Originally Posted by leamassiot View Post
Hi Mike, thank you for being happy .
I am not so happy because:

(4) Now, 192.168.2.4 can ping 192.168.0.4 and, for example 192.168.0.202.

(5) But, but but... 192.168.0.4 cannot ping neither 192.168.2.4 nor, for example 192.168.2.14.
Why is that so???

Please help,
all the best,
--
Léa
So close.

For 192.168.0.4 to ping 192.168.2.4 this is how the packets travel...

10.8.0.2->10.8.0.5->192.168.2.4->10.8.0.5->10.8.0.2

This assumes that you didn't tell ping which interface to use.

We know that 10.8.0.2->10.8.0.5 and 10.8.0.5->10.8.0.2 work because these two links are also used when we ping the other way, and that works. So we're left with two links

10.8.0.5->192.168.2.4 and 192.168.2.4->10.8.0.5

Your routing table is right, so 192.168.2.4->10.8.0.5 is ok.

Which leaves 10.8.0.5->192.168.2.4 which should be taken care of by the IP forwarding on that machine. Did you forget?

Mike
 
Old 08-05-2009, 01:22 PM   #14
leamassiot
Member
 
Registered: Dec 2005
Location: France
Distribution: Debian
Posts: 123

Original Poster
Rep: Reputation: 17
Code:
Which leaves 10.8.0.5->192.168.2.4 which should be taken care of by the IP forwarding on that machine. Did you forget?
Yes, I forgot... Please tell me how to do that!!!

Thanks,
all the best,
--
Léa
 
Old 08-05-2009, 02:28 PM   #15
mjsurette
Member
 
Registered: May 2005
Distribution: spiral, fedora
Posts: 65

Rep: Reputation: 18
Quote:
Originally Posted by leamassiot View Post
Code:
Which leaves 10.8.0.5->192.168.2.4 which should be taken care of by the IP forwarding on that machine. Did you forget?
Yes, I forgot... Please tell me how to do that!!!

Thanks,
all the best,
--
Léa
As per the OpenVPN FAQ...

echo 1 > /proc/sys/net/ipv4/ip_forward

Didn't you do this on the 192.168.0.4 machine? This is the magic command that allows interfaces to pass packets to each other.

Actually, I suspect that the sysctl.conf entry 'net.ipv4.ip_forward' probably does that too, but you may have to reboot, or at least restart your network for it to take effect. The echo command above takes effect immediately, but is cleared by the next boot.

Mike
 
  


Reply



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 Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenVPN Tun/Tap error Penn Linux - Server 5 10-14-2010 02:35 PM
Need help on TUN/TAP vinodl Linux - Networking 1 06-22-2009 11:18 AM
tun tap query karan84 Linux - Networking 1 03-26-2007 11:29 AM
tun tap doubt karan84 Linux - Networking 2 01-10-2007 01:43 AM
Tun/Tap issue minasafwat Linux - Kernel 0 11-14-2006 01:11 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 03:49 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration