# openvpn and PUSH_REPLY messages in the log [solved]

## mani001

Hi,

I need to set up a VPN to connect to the computer that is at my work (they won't allow just ssh    :Evil or Very Mad:  )...sooooooo...in order to learn how to do it, I tried to set up a VPN (following Gentoo wiki and some other guides around) between my laptop and my desktop computer, both connected to the same router...and it doesn't work, of course   :Sad:  Well, on both ends I can see the virtual interfaces created and everything looks fine, but when I tried to ping the server from the client, I get no reply and in the log I can see:

```

Sun May 23 11:30:43 2010 192.168.1.131:54433 [manu] Peer Connection Initiated with 192.168.1.131:54433

Sun May 23 11:30:43 2010 manu/192.168.1.131:54433 MULTI: Learn: 10.1.0.6 -> manu/192.168.1.131:54433

Sun May 23 11:30:43 2010 manu/192.168.1.131:54433 MULTI: primary virtual IP for manu/192.168.1.131:54433: 10.1.0.6

Sun May 23 11:30:45 2010 manu/192.168.1.131:54433 PUSH: Received control message: 'PUSH_REQUEST'

Sun May 23 11:30:45 2010 manu/192.168.1.131:54433 SENT CONTROL [manu]: 'PUSH_REPLY,route 10.1.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.1.0.6 10.1.0.5' (status=1)

```

The first 3 lines seem ok, but the last two don't look good. I've redirected the VPN port in my router (9900) to the server (192.168.1.129) and stopped iptables just in case...and I'm at my wits' end   :Sad:   Any help would be appreciated.

My server.conf

```

port 9900

proto udp

dev tun

#ifconfig 192.168.0.22 192.168.0.21

mode server

ca /usr/share/openvpn/easy-rsa/keys/ca.crt

cert /usr/share/openvpn/easy-rsa/keys/server.crt

key /usr/share/openvpn/easy-rsa/keys/server.key

dh /usr/share/openvpn/easy-rsa/keys/dh1024.pem

#server 192.168.0.16 255.255.255.240

server 10.1.0.0 255.255.255.0

client-to-client

ifconfig-pool-persist ipp.txt

#client-config-dir ccd

keepalive 10 120

tls-auth ta.key 0

#tun-mtu 1500

#tun-mtu-extra 32

#mssfix 1200

#duplicate-cn

comp-lzo

max-clients 100

persist-key

persist-tun

status openvpn-status.log

log        /var/log/openvpn.log

log-append /var/log/openvpn.log

verb 3

#user openvpn

#group openvpn

```

and my client.conf

```

client

dev tun

#ifconfig 192.168.0.21 255.255.255.240

ifconfig-nowarn

proto udp

remote 192.168.1.129 9900

resolv-retry infinite

nobind

#tun-mtu 1500

#tun-mtu-extra 32

#mssfix 1200

persist-key

persist-tun

ca "/etc/openvpn/client/ca.crt"

cert "/etc/openvpn/client/manu.crt"

key "/etc/openvpn/client/manu.key"

tls-auth "/etc/openvpn/client/ta.key" 1

comp-lzo

verb 3

#user openvpn

#group openvpn

log             /var/log/openvpn.log

log-append      /var/log/openvpn.log

```

GreetingsLast edited by mani001 on Sun May 30, 2010 12:04 pm; edited 1 time in total

----------

## erik258

Your configs look OK and I don't see anything particularly telling in your logs.   From what I see here, I'm wondering what your routing tables and interfaces look like after connecting to your vpn.  

Can you please post `ifconfig`  and `route -n` on both systems?

----------

## mani001

On the server side:

```

cochi manu # ifconfig

eth0      Link encap:Ethernet  HWaddr 00:1d:92:62:fa:3c

          inet addr:192.168.1.129  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:27963 errors:0 dropped:0 overruns:0 frame:0

          TX packets:27830 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:23995926 (22.8 MiB)  TX bytes:4213323 (4.0 MiB)

          Interrupt:28 Base address:0x6000

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:57 errors:0 dropped:0 overruns:0 frame:0

          TX packets:57 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:3758 (3.6 KiB)  TX bytes:3758 (3.6 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          inet addr:10.1.0.1  P-t-P:10.1.0.2  Mask:255.255.255.255

          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:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

```

```

cochi manu # route -n

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.1.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0

10.1.0.0        10.1.0.2        255.255.255.0   UG    0      0        0 tun0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

```

On the client side, while pinging (with no reply):

```

eth0      Link encap:Ethernet  HWaddr 00:22:19:e9:d6:d7

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

          Interrupt:17

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:62 errors:0 dropped:0 overruns:0 frame:0

          TX packets:62 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:5086 (4.9 KiB)  TX bytes:5086 (4.9 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          inet addr:10.1.0.6  P-t-P:10.1.0.5  Mask:255.255.255.255

          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:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:22:fb:55:01:60

          inet addr:192.168.1.131  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1124 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1174 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1037392 (1013.0 KiB)  TX bytes:134902 (131.7 KiB)

wmaster0  Link encap:UNSPEC  HWaddr 00-22-FB-55-01-60-00-00-00-00-00-00-00-00-00-00

          UP RUNNING  MTU:0  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

```

```

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.1.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0

10.1.0.0        10.1.0.5        255.255.255.0   UG    0      0        0 tun0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0

```

----------

## erik258

You're using point-to-point VPN configuration.  I'm not too familiar with this, find it confusing and not at all logical like ethernet.  That's why I always use layer II virtual ethernet devices with tap* rather than layer III ip virtual devices with tun.  But what you're wanting to do - I think - should work.  

The interesting thing I see, looking at your config, is that the server has a p-to-p between 1 and 2, and the client has a p-to-p between 5 and 6.  I can see that both appear to have logical routes to those networks.  Try pinging both of the remote addresses from both clients.  I think you may find that of the 4 listed ips, only one is accessible from each host.  I'd try putting that IP as the route for that network.  Unfortunately, I am not sure which it is.  See why I'm confused?  You have 2 endpoints, 4 ips, and even though they're all on the same subnet they can't talk to each other.

Your other option is to use a configuration like I do, which I use in all sorts of environments including inter-datacenter communication and works very well, and much more logically (like a virtual ethernet between constituants).  I put up server and client configs just in case you're interested in them: http://spore.ath.cx/~dan/openvpn-configs/

----------

## mani001

sorry for the delay...and thank you very much for your help!!

 *Quote:*   

> 
> 
> Try pinging both of the remote addresses from both clients. I think you may find that of the 4 listed ips, only one is accessible from each host
> 
> 

 

yes, exactly

 *Quote:*   

> 
> 
> I'd try putting that IP as the route for that network.
> 
> 

 

I don't really know how to do that   :Embarassed:  On the server side, for instance, I can see

```

10.1.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

```

and I'm guessing it should be something like

```

10.1.0.2        10.1.0.1         255.255.255.255 UH    0      0        0 tun0

```

since  10.1.0.1 is the ip that can be pinged from the server (its endpoint)

Anyway, I think I must have missed something because from what I've read I shouldn't have to do that kind of tweaking (If I was doing it right, of course  :Smile:  )

About your solution, is it as simple as replace my server and client config files? doesn't that imply to create a network bridge or something like that? In

[url]

http://en.gentoo-wiki.com/wiki/Road_Warriors_with_OpenVPN

[/url]

they also use dev tan and they talk about bridged vpn...

----------

## erik258

Hi!  

I'm going to do my best to describe this both technically and in a way that is fairly easy to digest.  I'm not a network engineer, by which I mean I'm not an expert on what I'm talking about here.  This is my working understanding, and I'm using it in a number of production environments.  You'll have to excuse me if I use the wrong word here or there or if there are little bits and pieces that are phrased oddly.  In that case, I'm sure somebody will correct me.  

Once we talk about this stuff (which, if you understand, you should skip) we can talk about what you are likely to need for your VPN.  

Virtual Networks, Bridging and Routing 

Visualize a layer 2 virtual network (that is, a vpn using tap devices) as an Ethernet network just like any other.  The only difference is, instead of physically connecting each participant to the network switch or hub with a patch cable, we connect to the virtual network with an openvpn connection.  But once connected, it's an Ethernet network just like any other*.  

So let's consider the bridging configuration in that light.  When you bridge to physical Ethernet networks, you effectively turn the two physical interfaces into an Ethernet cable between the two physical networks - in other words, the two networks become one broadcast domain.  The bridging code in the kernel handles this much like the switching fabric in a plain old network switch does; it routes traffic meant for one network or the other.  In this way, computers on network A can add a route to network B just like they did in network A.  

To look at this a little closer, we'll need some variables.  Let's say network A is 10.1.0.0/24.  Network B is 10.2.0.0/24.   Computer A1, on network A, has a route something like this:

```

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.1.0.0         *                    255.255.255.0  U      0        0       0     eth0

```

This tells A1 that it is on the same broadcast domain as all of 10.1.0.0/24 and can speak directly to the rest of the subnet.  So when A1 wants to talk to A2, also on network A, it doesn't need to route it's packets through a router, it can just send them straight to the hardware address that corresponds to A2's IP address.  (ARP would be used to do that).  

Computer B1 also has a route straight to its local subnet: 

```

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.2.0.0         *                    255.255.255.0  U      0        0       0     eth0

```

And the same is true of traffic between B1 and B2.  They are physically connected and can communicate directly with each other.  

Now let's say that network A and network B are actually using the same switch.  A1 is configured with an ip address in A's subnet, and B1 is configured with an  ip address in B's subnet.  But they can still address both networks; they are directly connected to both.  All A1 needs to talk to B1 is to be told that, just as with network A, it can communicate directly with network B.  A route command like this would tell A1 just that.  

```
route add -net 10.2.0.0/24 dev eth0
```

OK, let's take this one step further.  Let's say A and B are both connected to different switches, but between the switches runs an Ethernet cable.  You probably know that you can plug one switch into another, making them act like one big switch**.  So they are actually plugged into 2 different switches, but since those switches are connected, they act like one big switch.  

Finally we've reached the topic of bridging.  Let's go back to the first configuration: A and B are on separate switches and they are not connected with an Ethernet cable.   But connected to both switches is a computer C1.  C1 has an interface on network A, and an interface on network B.  It can talk to both networks.  

If C1 was configured to bridge its 2 interfaces, the linux kernel bridging code would make the 2 network cards act like a cable between the two networks.  Because the interfaces were bridged, traffic could flow freely between the two networks as if they were connected to one switch - one 'broadcast domain'.  

The alternative, if you wanted to use C1 to connect the two networks, would be to route.  Computers in network A would be told to send traffic meant for network B through C1, and B's participants would do the same.  We'd better call C1's addresses 10.1.0.99 and 10.2.0.99 respecively.  C1 would be told to forward ip traffic (echo 1 > /proc/sys/net/ipv4/ip_forward), computers on A would be told "route add -net 10.2.0.0/24 gw 10.1.0.99" and computers on B would be told "route add -net 10.1.0.0/24 gw 10.2.0.99".  In so doing, we give computers on A and B an address they can talk to - 10.{1,2}.0.99 - to use to talk to addresses they can't otherwise talk to.  

Routing between subnets is what I use in place of bridging as it's described in the road warrior's guide (which, incidentally, is where I learned how to use VPNs).  If I'm sitting at the coffeeshop - as I am now - I don't want anybody to talk to networks I'm connected to.  Instead, I want to have to tell A and B they can talk to each other.  This allows me to use one VPN server to connect all sorts of physically remote networks together, and allows the VPN endpoints to route traffic if desired.  If all the computers were bridged to the VPN, they'd have to use a special kind of netfilter rules that can be applied to bridged interfaces to stop this from happening.  In my configuration, the computers - on both sides - have to be told about each of the other networks.   Even if somebody at the coffeeshop knew the IP addresses of the servers on one of the VPNs I'm connected to, and knew my IP address at the coffeeshop, they still couldn't talk to each other unless I allowed my machine to forward packets, and told the servers about the network on the coffeeshop side of my machine.  That's why I don't use bridging.  

If you install iptables on one of your vpn endpoints, you can use Masquerading to hide the VPN machines behind the endpoint.  All traffic from the vpn will appear to come to that endpoint.  Thus you can set up a VPN endpoint on a network and then connect to any machine on that network through the VPN.  But as the administrator of the VPN, you get to decide whether the computers are connected and whether the reverse is true.  The network behind the endpoint doesn't need a route but the computers on the other side of the VPN do.  

Your Configuration

Chances are, all that stuff, while perhaps helpful for conceptualizing the situation, and perhaps educational for you or for others, doesn't actually relate to you.  It just describes what bridging would do, and why you might or might not want to do it.  I also threw the masquerading part in there just in case you're interested in how you can talk to any computer on the network at your work through the vpn without changing their routing tables.  

But if you just want to connect to the computer remotely, all of this information is actually overkill.  All you need to know is the very first part: a virtual layer II network acts just like a real one.  

You'll have to run a VPN server on an external address - on one side or the other, it doesn't really matter so much which is the server and which is the client - and connect to that address from the other side of the VPN.  Then you can talk directly to the remote end of the VPN just as you'd expect.    The VPN config I threw up - and yours, if you were using tap devices - should be sufficient for that, if i'm not mistaken.  

If you wanted to connect a remote network to the network at your work, bridging or routing would work to do that.  Bridging would negate the need for routing on the bridge (although the networks would still need to be told they can talk to each other).  Routing would give you more control over traffic between the networks without making the intermediary computer a bridging firewall.  Masquerading would remove the need for routing all together, at the expense of firewalling one network off.  

Moving Forward

Well, that's about everything I know about the conceptual design of virtual private networks and their interaction with physical networks.  Now that we've gotten all that out in the open, I can continue to advise you  on your own situation.  

 *Quote:*   

> About your solution, is it as simple as replace my server and client config files? 

 

Very nearly.  You'll have to make sure the key and certificate files are properly identified and that the server's hostname or IP address is correct.  Other than that, yes, they should just drop right into place.  

 *Quote:*   

> doesn't that imply to create a network bridge or something like that?

 

I think you can probably answer this one yourself at this point.  In short, no.  You don't need to bridge the 2 and I never do.  You may bridge the networks if you want to create one big network.  You may route the networks if you want to make the distinct networks talk to each other, and possibly to networks beyond.  Or (and I think this would be appropriate for you) you may simply connect VPN participants to a new virtual network, and not connect physical networks through it at all.  

Incidentally, 

 *Quote:*   

> I need to set up a VPN to connect to the computer that is at my work (they won't allow just ssh :evil: )

 

Depending on where your work computer is, the admins' policy make a lot of sense.  To ssh into your work computer, It'd need a external address or a port forward on the work side.  However, connectivity like this doesn't necessitate a VPN.  You could also use a variety of IP tunneling mechanisms, most simple of which an SSH tunnel.  Such a tunnel would 'punch a hole' through all the firewalls at your work and connect to, say, a public IP at your house.  Then you'd connect to a port on that box and your traffic would be sent through the tunnel to your work's computer.  But a VPN gives you the added benefit of opening up all the ports on your work machine, and (potentially against the wishes of your local sysadmins, who fortunately don't know who I am ; ) you could even masquerade on your work computer to let you get into all sorts of mischief (read: get productive work done) on the work network at home.  

Sorry there's so much.  I just wanted to explain bridging but it turned into a little article, didn't it? 

Good luck and let me know what more I can help with.

-- DF

Notes

* The same would be true, I believe, of a layer III virtual network -- ie one created with tun devices.  But the default in these cases is to use these wierd point-to-point connections.  There's a way to make it act more like a tap network, but at that point, it seems as though you may as well just use tap devices.  I have seen it described but I don't know where.

** Historically you had to use an UPLINK port to do this.  If you've been connecting Ethernet networks long enough you probably remember switches/hubs with uplink ports, or special crossover cables used to do this.  Modern switches, like most modern network cards, are auto-sensing and will cross their RX and TX if necessary, effectively making a patch cable into a crossover cable and working without using a special crossover cable or an uplink port.  Auto-sensing ports are the norm, and modern switches don't have uplink ports or buttons to toggle a port between normal and uplink.    Connecting switches like this means that all traffic between the two switches must travel over the one inter-switch cable, so it introduces a bottleneck that wouldn't exist on one big switch; that's why 24 port switches are still expensive even though 3 8 port switches are dirt cheap.  But conceptually, they act like one big switch, even though they don't perform like one.

----------

## mani001

Here I go again  :Smile: 

First of all, thank you very much for your time!!...you wrote a really nice introduction to VPN's and some other related concepts..

Unfortunately, this is not working for me either  :Sad: 

A couple of things:

- in the

```

user nobody

group nobody

```

part, shouldn't it be "openvpn" instead of "nobody"? I think Gentoo creates user and group "openvpn" when you emerge the packet... Anyway, using either "nobody" or "openvpn" I get

this in the client:

```

"WARNING: You are dropping root privileges!"

                        "As such openvpn may not be able to change ip,routing"

                        "or DNS configuration."

```

is this normal? Also, in both cases I get

```

SIOCSIFADDR: Permission denied

SIOCSIFFLAGS: Permission denied

Sat May 29 11:31:32 2010 us=99184 Linux ip addr del failed: external program exited with error status: 255

Sat May 29 11:31:32 2010 us=108478 SIGTERM[hard,] received, process exiting

```

in the log. I tried taking out the user/group "whatever" part and it doesn't work either. 

- it probably doesn't matter since this is working for you but...the "tls-client" option in the client.conf is not documented in http://svn.openvpn.net/projects/openvpn/trunk/openvpn/sample-config-files/client.conf

Summing it all up, I'm still getting

```

Sat May 29 11:31:35 2010 us=737804 192.168.1.131:53249 [manu] Peer Connection Initiated with 192.168.1.131:53249

Sat May 29 11:31:36 2010 us=152545 manu/192.168.1.131:53249 PUSH: Received control message: 'PUSH_REQUEST'

Sat May 29 11:31:36 2010 us=152645 manu/192.168.1.131:53249 SENT CONTROL [manu]: 'PUSH_REPLY,route 10.1.0.0 255.255.255.0,route-gateway 10.1.0.1,ping 30,ping-restart 120,ifconfig 10.1.0.4 255.255.255.0' (status=1)

Sat May 29 11:31:36 2010 us=348529 manu/192.168.1.131:53249 MULTI: Learn: 12:29:d1:4d:b6:fb -> manu/192.168.1.131:53249

```

in the server log just after starting the client (I noticed that I don't even have to ping to get that).

I also tried adding routes (I now understand this, I think   :Rolling Eyes:  , after reading your previous post  :Smile:  ) in order to specify on the server side that all the packets for the other endpoint of the VPN should be sent to its endpoint of the VPN

```

10.1.0.0        10.1.0.1        255.255.255.0   UG    0      0        0 tap0

```

(10.1.0.1 is, apparently, the endpoint on the server and can be pinged)

Afterwards, I did likewise in the client. It didn't help...and anyway, should I have to do something like this?

I don't know what I'm doing wrong but it must be really bad   :Confused: 

Any other idea/suggestion?

----------

## erik258

All right, let's get this fixed up.  

 *Quote:*   

> 
> 
> ```
> 
> user nobody
> ...

 

Sure, either way.  I don't honestly know why I'm using 'nobody' but it's probably because I set it up that way on some BSD boxes which don't have emerge - or something that.  The important thing is, root privileges are being dropped so that openvpn isn't running as root.  This is for security's sake, although it's unlikely that openvpn would be easily compromised.  But either should work - or none.  

 *Quote:*   

> 
> 
> ```
> 
> "WARNING: You are dropping root privileges!"
> ...

 

I see that in my logs too.  But it doesn't actually stop me from doing any of those things.   However, 

 *Quote:*   

> 
> 
> ```
> 
> SIOCSIFADDR: Permission denied
> ...

 

... in your case you might want to see what happens if you take the user and group lines out all together.  

 *Quote:*   

> Summing it all up, I'm still getting [ ... ] 

 

Those messages are nominal.  

 *Quote:*   

> 
> 
> the "tls-client" option in the client.conf is not documented in http://svn.openvpn.net/projects/openvpn/trunk/openvpn/sample-config-files/client.conf

 

Perhaps not, but it's documented in the man page for openvpn.  

 *Quote:*   

>  [setting up routing ] didn't help...and anyway, should I have to do something like this?

 

Typically 'push' is used to send clients routing info for the vpn and possibly beyond; 'pull' is then used to retrieve this on the client.  I don't use any extra route commands to connect to my vpn.  

 *Quote:*   

> Any other idea/suggestion?

 

Can you please post openvpn config from client and server, and information for your tun/tap devices on both, and the routing tables on both, so I can see what's going on?

----------

## mani001

It's working now!!   :Very Happy:   I think I'm dumb: I had forgotten to turn off iptables   :Embarassed:   but, for the record, not from the beginning, only las time I tried (with your configuration)   :Rolling Eyes:  Anyway I just had to add a rule to allow the 10.1.0.0 subnetwork and that's it.

Thank you very much erik258.

----------

