# route tap0 to eth0 [solved]

## julmust

I've set up openvpn and everything seems to work - i can reach the virtual IP of the vpn server from the clients and vice versa. From the clients also eth0 on the vpn server can be reached, however none of the other hosts in the remote subnet can be reached.

The question is of course, how do I route traffic via tap0 to go out on eth0 so other computers in the subnet can be reached? 

This is the current route config of the server:

```

PC01_server ~ # route -N

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

```

192.168.0.0/24 is the remote subnet

192.168.100.0/24 is the virtual subnet

Also, ip forwarding is enabled

```

PC01_server ~ # cat /proc/sys/net/ipv4/ip_forward

1

```

The clients are configured to route all requests to 192.168.0.0/24 via 192.168.100.100, the virtual ip of the vpn server.

Any ideas?

----------

## Raffi

If you want your clients to be able to reach machines on the local network of the server, push the route from the server config file. Add a line like

```

push "route 10.15.0.0 255.255.0.0"

```

Replace the 10.15... with your network and subnet mask.

----------

## julmust

I've done this already, i have

```

push "route 192.168.0.0 255.255.255.0 192.168.100.100"

```

Doesn't this just tell the clients to go throught 192.168.100.100 when attempting to reach the 192.168.0.0 subnet? I seems like the problem is on the server.

----------

## Raffi

Yes, that tells the clients how to find a subnet on the server. To have the server find a subnet on the clients you will need to specify the route via iroute. To only use this on a client that has a subnet you are interested in use the client-config-dir option.

```

client-config-dir somedir

```

In somedir put a file with the name of the client (name comes from the common name of the key) with the iroute command in it

```

iroute 10.15.0.0 255.255.0.0

```

----------

## troymc

So far you've only mentioned the route for the VPN machines to talk into the local net.

Don't forget your reverse route so that your local machines know how to respond back to the VPN machines.

troymc

----------

## julmust

 *troymc wrote:*   

> So far you've only mentioned the route for the VPN machines to talk into the local net.
> 
> Don't forget your reverse route so that your local machines know how to respond back to the VPN machines.
> 
> 

 

This is absolutely true! I can't believe I overlooked this.. i will try this later when I have physical access to the remote computers. However, it seems like I no longer can ping the client from the server. I don't know what I've done. I still can ping the vpn virtual ip from the client, and also the eth0 interface of the server. Isn't that kind of weird? If the client can ping the server, the server would be able to find the client, in my opinion.

The routing table is the same, all requests to 192.168.100.0/24 on the server goes through tap0.. Even if this was wrong pinging like this (where 192.168.100.101 is the client IP address):

```

ping -I tap0 192.168.100.101

```

would take care of that i guess.. 

What did I mess up now?

----------

## Raffi

If the endpoints of the vpn are the gateways for the network, the routes should work themselves out. If not, you will definitely need to deal with it.

That said, you will need to use iroute to route to a subnet on the client. I do this for one of my clients and I could not get anywhere until I did it this way.

----------

## julmust

The VPN server is not the default gateway on the remote subnet, so I guess that needs to be taken care off. I'm not quite sure what you mean about iroute, but I don't want the computers on the remote subnet connected to the VPN to be able to reach the clients subnets. 

As far as I follow I need to do this:

- Make sure computers on remote subnet 192.168.0.0/24 route traffic to the virtual ip range 192.168.100.00/24 to the VPN server (in my case 192.168.0.200). Would the VPN server then automagically forward this traffic out on tap0?

- It would also be really great if I could reach connected clients from the VPN server. Any ideas why clients can ping the virtual address of the VPN server, but not the other way around?

----------

## Raffi

I may not be following what you are trying to do. Given the following

client subnet - client ---- internet --- server - server subnet

to allow the client or the client subnet to reach the server subnet you need to push a route. To allow the server or the server subnet to reach the client subnet you need to use iroute.

----------

## julmust

I want to allow the clients to reach the server subnet, thus I have pushed a route. I don't want the server subnet to reach the client subnet. Won't this mean I don't need to use iroute? Clients will talk over their virtual IP to the server subnet and the server subnet will respond to the clients virtual ip address. Am I right or am I way off?

----------

## Raffi

That is correct, you won't need iroute. Just push a route (the first answer I posted has what you need). Since your server is not the default gateway, you will need to make sure your server subnet knows how to get back to the client. Either add static routes to each machine or use a routing daemon to keep them updated.

----------

## julmust

Okey, great.. the only thing left is to figure out why I can't ping the vpn client from the vpn server, this would be a good thing if I want the rest of the computers on the remote subnet to also do this, I guess.

Any ideas what could have screwed this up? As I said, I can ping the virtual vpn address from the client but not the other way around.

----------

## Raffi

The things to look for are routes and firewalls. You can use tcpdump to watch traffic and see where it is going. You would need to post your config files and details about the rest of your configuration for me to be able to be more specific.

----------

## julmust

This is my setup:

192.168.0.0/24 - remote subnet

192.168.100.0/24 - virtual subnet

192.168.1.0/24 - client subnet

serverconf:

```

port 1194

dev tap

tls-server

ca /etc/openvpn/server/ca.crt

cert /etc/openvpn/server/server.crt

key /etc/openvpn/server/server.key

dh /etc/openvpn/server/dh1024.pem

tls-auth /etc/openvpn/server/static.key  0

duplicate-cn

mode server

ifconfig 192.168.100.100 255.255.255.0

ifconfig-pool 192.168.100.101 192.168.100.105 255.255.255.0

push "dhcp-option DNS 192.168.0.1"

push "route-gateway 192.168.100.100"

mtu-test

tun-mtu 1500

tun-mtu-extra 32

mssfix 1450

ping 10

ping-restart 120

push "ping 10"

push "ping-restart 60"

push "route 192.168.0.0 255.255.255.0 192.168.100.100"

push "route 192.168.100.0 255.255.255.0 192.168.100.100"

comp-lzo

```

client config:

```

port 1194 # or any other port you want to use

dev tap

remote remote-address #is external IP of the OpenVPN server

tls-client

ca ca.crt

cert client.crt

key client-key.txt

tls-auth static-key.txt 1

mtu-test

tun-mtu 1500

tun-mtu-extra 32

mssfix 1450

pull

comp-lzo

verb 4

```

The whole thing is like this:

Client - Firewall - Internet - Firewall - VPN server

I've redirected port 1194 on the remote firewall to the VPN server. What else is there to do?

----------

## Raffi

Most of that looks pretty good. The place I would expect problems would be the client firewall. Is that a separate machine or a firewall running on the client? If it is running on the client, you will want to make sure you are passing traffic from the vpn.

What does the output of route -n look like on the server and on the client with the vpn up and running?

----------

## julmust

The firewall/gateway in front of the client is a d-link dfl-200. In my opinion it should be no problem, the firewall would allow traffic since it's the client that initiate the connection. 

route -n on server:

```

PC01_server openvpn # route -N

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

```

route PRINT on client (since its windows xp)

```

Gränssnittslista

0x1 ........................... MS TCP Loopback interface

0x2 ...00 13 d4 43 df d6 ...... Realtek RTL8139 Family PCI Fast Ethernet NIC -

iniport f÷r paketschemalõggning

0x3 ...00 ff c0 12 f8 ba ...... TAP-Win32 Adapter V8 - Miniport f÷r paketschema

õggning

===========================================================================

===========================================================================

Aktiva vägar:

   Nätverksadress          Nätmask   Gateway-adress      Gränssnitt    Mått

          0.0.0.0          0.0.0.0     192.168.1.99    192.168.1.45       20

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

      192.168.0.0    255.255.255.0  192.168.100.100  192.168.100.101      1

      192.168.1.0    255.255.255.0     192.168.1.45    192.168.1.45       20

     192.168.1.45  255.255.255.255        127.0.0.1       127.0.0.1       20

    192.168.1.255  255.255.255.255     192.168.1.45    192.168.1.45       20

    192.168.100.0    255.255.255.0  192.168.100.101  192.168.100.101      30

    192.168.100.0    255.255.255.0  192.168.100.100  192.168.100.101      1

  192.168.100.101  255.255.255.255        127.0.0.1       127.0.0.1       30

  192.168.100.255  255.255.255.255  192.168.100.101  192.168.100.101      30

        224.0.0.0        240.0.0.0     192.168.1.45    192.168.1.45       20

        224.0.0.0        240.0.0.0  192.168.100.101  192.168.100.101      30

  255.255.255.255  255.255.255.255     192.168.1.45    192.168.1.45       1

  255.255.255.255  255.255.255.255  192.168.100.101  192.168.100.101      1

Standard-gateway:      192.168.1.99

===========================================================================

Beständiga vägar:

  Inga

```

Windows XP output in swedish, hopefully it makes sense anyways!

----------

## Raffi

I agree about the linksys.

The server side looks good, but the client side does not make much sense (not that routing on windows ever really makes sense). I will have to setup a windows client and see what things look like before I can tell if there is a problem with that side.

----------

## julmust

Do you think it's the client? The client can ping the server, hence it redirects requests to the virtual vpn server to the right TAP interface. To me it seems like the servers ping request can't reach the client.. could it get lost because of the clients routing table?

I'll have to try some more later.. am on my way to London now.. i'll be back in a few days.

Thanks for the help so far!

----------

## Raffi

Ahhh I missed that part. Since the client can ping, the routes are OK.

Most likely, the problem is the server is pinging with the wrong address. Do you have a net monitoring program you can use on the windows client? If so, you should see the ping request but you will probably see it from an unexpected address.

What is the output of ifconfig on the server?

----------

## julmust

```

PC01_server openvpn # ifconfig

eth0      Link encap:Ethernet  HWaddr 00:E0:4C:90:96:46

          inet addr:192.168.0.200  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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

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

          collisions:0 txqueuelen:1000

          RX bytes:394613096 (376.3 Mb)  TX bytes:3283162154 (3131.0 Mb)

          Interrupt:18 Base address:0xb000

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:10491 errors:0 dropped:0 overruns:0 frame:0

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

          collisions:0 txqueuelen:0

          RX bytes:535590 (523.0 Kb)  TX bytes:535590 (523.0 Kb)

tap0      Link encap:Ethernet  HWaddr 6E:2C:7B:89:FD:97

          inet addr:192.168.100.100  Bcast:192.168.100.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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

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

          collisions:0 txqueuelen:100

          RX bytes:28674 (28.0 Kb)  TX bytes:27602 (26.9 Kb)

```

I'll try to connect with a linux client later, i'll get back to you about how that goes.

----------

## Raffi

I setup a windows client to my vpn and the route you show above looks OK. I doubt that I will ever get used to window's routing.

----------

## julmust

I analyzed the network traffic in Ethereal on the client side, and I can't say that made me any wiser...

When I try to ping the client from the server, the client receives ping requests. However, it does not respond.

The source of the ping request is reported to be the IP address of the server, 192.168.100.100 and the destination is obviously the clients IP address, 192.168.100.101. Even the MACs of the virtual adapters are right. 

What can be wrong? The other way around, pinging server from client, works and looks perfectly normal in Ethereal.

EDIT:

Okey, this is just plain stupid. Turned out Windows had enabled a firewall for the OpenVPN virtual adapter, causing it to block the ping replies... ARGH!!! 

Anyway, thanks again for your help Ruffi.

----------

