Hello there,

I´ve been trying to establish a vpn (openvpn) connection between two linksys.

LAN SubNet (10.10.1.0) -->(10.10.1.80) Server WRT VPNLNK(192.168.100.1)<----->(192.168.100.2)Client WRTVPN(10.10.1.86)--> LAN Subnet(10.10.1.0)

I need a VPN server on my lan to be able to establish communication with the machine on the remote location. I´ve tried bridged with no success and routing with no success either. Can you give me a hint? I have RC5 functioning well with ppp0 estaablishing good connections. I´ve managed to actually ping each WRT with success in the tunnel, but the machines cannot comunicate.

(Last edited by Pessanha on 16 Aug 2006, 12:55)

To get things little more explained heres an image of what i wanted:

Right now i´ve managed to get linksys to ping each other. Inside de linksys openvpn server i can ping the machine behind the linksys ClientVPN. But inside the lan, i cannot ping the subnet machine client  neither the client VPN linksys. I now its got to do something with the openvpn server beeing a host and not he default gateway. Any help?

Heres my config files:

VPN SERVER:

port 1194

proto udp

dev tun
ifconfig 192.168.100.1 192.168.100.2

#keepalive 10 120

comp-lzo

ping 15
ping-restart 300
resolv-retry 300
ping-timer-rem
persist-key
persist-tun

verb 5

route 10.10.1.86 255.255.255.255
route 10.10.1.100 255.255.255.255

VPN CLIENT:

dev tun

proto udp

remote xxx.xxx.xxx.xxx 1194

ifconfig 192.168.100.2 192.168.100.1

#keepalive 10 120

comp-lzo

verb 5

route 10.10.1.0 255.255.255.192
route 10.10.1.64 255.255.255.240
route 10.10.1.80 255.255.255.252

---------#------------------------------

I can Ping from the wrt server to the machine in the client wrt subnet. bt cannot ping from the server subnet to the client subnet and vice versa.

Should i establish route in the lan gateway where the vpn server (HOST) is in? Because the vpn server is not the default gateway...

(Last edited by Pessanha on 18 Aug 2006, 15:19)

Just edited the last post. Anyone with a similar problem?

What does logread on the server show when you try to ping from a host behind the client to a host behind the server?  I bet it's saying something like "MULTI: bad source address from client [w.x.y.z n], packet dropped". (where w.x.y.z is the IP address of your client).

It doesn't look like you have a "client-config-dir" directive in your server config.  Without that, and the associated "iroute" command in the client file (on the server), you're never going to route.  You can verify this with the error message above.

See the openvpn 2.0 howto server sample config and look for the iroute statement (it goes in the client file on the server, not the client)

Also, re-read the section on routing.  It's very confusing at first (even for network engineers!) because of the way OpenVPN does "internal" routing.  You need to read it a few times to understand what they're doing. 

So, the long and the short is, your "route" command are probably correct, but you also need "iroute" commands to complete the routing config.

G

edited to include the correct error message after I googled it up :-)

(Last edited by bluesguy on 18 Aug 2006, 12:34)

Hi there. Thanks for the reply.

Actually my first experience with the config files in opnevpn was having that clause client-config-dir with multi-clients configuration.  But that didn't work. I only have one client at the moment (going to have more later) so i don´t think i need to create that file.

I tried logread and it doesn´t show me nothing. no message no error.

Make sure you understand the difference between the 'push "route x.w.y.z/nn"', 'route', and 'iroute' directives.  If you're using the 'route' directive you MUST have an associated 'iroute' directive or your traffic WILL NOT GO THROUGH.

A 'push "route w.x.y.z/nn"' on both sides advertises the subnet behind the local WRT to the remote WRT on the other end (although it could be used for other purposes).  In other words,  the client pushes his network information to the server, and the server pushes his network information to the client, so that each end knows what the other end looks like.  This directive tells the remote end to add an entry to its routing table so that the remote end knows where to send traffic for the local end's subnet.

Alternatively you can use the 'route' and 'iroute' directives.  The 'route' directive changes the local routing table, typically for destinations somewhere behind the remote end.  If you do this, you MUST have an 'iroute' directive so that OpenVPN knows that it should allow this traffic to be routed. 

Both methods will allow hosts behind the local end to traverse the VPN and reach those destinations on the remote end without the hosts themselsves having to know the routes, since the router is doing the routing :-)

Now, if your OpenVPN endpoint (either client or server) isn't the default gateway for the hosts, then you need to do the above configuration, as well as adding routes to the host(s), so that they know when to use the OpenVPN tunnel, and when to use their default gateway.  In this case, the hosts are the one's making the routing decisions of which traffic to send to the OpenVPN endpoint, and which traffic to send to their default gateway.  When the host sends traffic to the OpenVPN endpoint, the OpenVPN endpoint still needs to know how to get to the other end of the VPN tunnel, so its routing table still needs to configured using one of the two methods described above first.

Again, the openvpn 2.0 howto describes all of this.

Also check your firewall.  You need to allow traffic on and off the tun devices.  Something like this is /etc/firewall.user should do the trick.

iptables -A forwarding_rule -i tun+ -o $LAN -j ACCEPT
iptables -A forwarding_rule -i $LAN -o tun+ -j ACCEPT

Sorry for the long winded answer on routing, but hopefully that helps.

G

Well, just wanted to let you know that i ve managed to put it to word in bridged mode. Being a host and not a default gateway, i needed to put some rules on my gateway firewall. Another error came up this morning (i left it communicating all night to test liability). When i tried the ping between server and client a error came up:

P_CONTROL_HARD_RESET_CLIENT_V2.

I know i have to establish some kind of ping routine so it doesnt  loose communication. Whats the best way?. I have a directive in server config which looks something like this:

keepalive 10 120

Is there a better way. Does the client need it also?

Thanks for your help.

Well, the information I was giving above was for routing mode.  For bridging mode, some of it is different.  The OpenVPN FAQ describes the differences.

To answer your question, you really need to use the keep alive directive on both ends.  From the OpenVPN 2.0.x man page:

--keepalive n m
    A helper directive designed to simplify the expression 
of --ping and --ping-restart in server mode configurations.

    For example, --keepalive 10 60 expands as follows:

         if mode server:
           ping 10
           ping-restart 120
           push "ping 10"
           push "ping-restart 60"
         else
           ping 10
           ping-restart 60

And from the --ping flag

"...specify --ping on both peers to cause ping packets 
to be sent in both directions since OpenVPN ping packets are 
not echoed like IP ping packets"

So, in other words, you need to use keepalive on both ends.

G

Yes, i have done that already today morning and its still alive. Put it in client also... Thanks for the help again.

Hello again,
Another problem came up. After the vpn established, i connect 1 client to the client wrt. After 5 or 10 minutes, it goes down. The client gives heavy traffic. After that i loose connections. I cannot ping internet nor the vpn link. The strange thing is that the ping does not show anything, no error no nothing. I cannot even test connectivity because of that.

Why that happens?

Bellow my client config

client
dev tap
proto udp
mssfix 1200
remote xxx.xxx.xxx.xxx 1194
up /etc/openvpn/up-script
down /etc/openvpn/down-script
resolv-retry infinite
nobind
keepalive 5 600
ping-timer-rem
persist-key
persist-tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key

comp-lzo

verb 4
mute 10

(Last edited by Pessanha on 3 Sep 2006, 17:53)

Solved my own problem. change PROTO to TCP and now everything is ok.

Be warned that TCP is not always optimal since you can have nasty TCP-over-TCP meltdown problems...
The should be a way to use UDP successfuly.

(Last edited by booBot on 4 Sep 2006, 22:25)

Well it just hanged on for 1 and a half days. Again it went down. The strange thing is that i cannot ping anything. It just doesnt respond. What sould i do?

It could be that the problem is with the firewall rules and the interface names on the linksys device.
I had a similar problem on a wrtsl54gs. Adding the following 5 lines to /etc/firewall.usr and restarting the firewall fixes the problem.

iptables -t nat -A prerouting_rule -i $WAN -p udp --dport 1194 -j ACCEPT
iptables        -A input_rule      -i $WAN -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i br0 -o tun+ -j ACCEPT

Without the last 3 lines, the vpn tunnel will come up and operate fine from the machines running openvpn, but all attempts to get traffic in or out of the lan behind the machines will just quietly fail.

Be sure to check, and possibly adjust the names of the interfaces for your specific setup.
tun is my name for the virtual tun device
   and
  br0 is the name the linksys device assigns to the lan interface