Reply To: LAN-to-LAN (site-to-site) VPN with tun device

Home Page Forums Network Management ZeroShell LAN-to-LAN (site-to-site) VPN with tun device Reply To: LAN-to-LAN (site-to-site) VPN with tun device

#48640
cyboc
Member

Fulvio,

As promised I have tried your suggestions and I am reporting my results back here to the forum.

The good news is that I was mostly successful in getting the lan-to-lan VPN working in routed mode with a TAP device. The bad news is, it was more difficult to get working than when using a TUN device, especially since the convenient openvpn iroute directive appears to be supported only with TUN device and not TAP device. Details are below:

On the client side, I used Zeroshell. After configuring in the Zeroshell GUI, here is the configuration that Zeroshell produced (taken from command line):


--dev VPN00
--remote foo
--port 1194
--proto udp
--tls-client
--dh /etc/ssl/dh.pem
--ca /etc/ssl/trusted_CAs.pem
--cert /var/register/system/net/interfaces/VPN00/TLS/cert.pem
--key /var/register/system/net/interfaces/VPN00/TLS/key.pem --dev-type tap
--float
--ping 1
--ping-restart 11
--management 127.0.0.1 34000
--daemon VPN00_L2L
--comp-lzo
--cipher AES-128-CBC
--pull
--verb 3
--down /root/kerbynet.cgi/scripts/vpn_mii

On the server side, I used Ubuntu server. Initially I tried configuring with the OpenVPN admin module for webmin. Unfortunately, that module forces you to use bridging mode if you select the TAP device. Therefore, I had to do manual configuration. Below is the configuration file I used.


port 1194
proto udp
dev tap0
ca keys/foo/ca.crt
cert keys/foo/server.crt
key keys/foo/server.key
dh keys/foo/dh2048.pem
server 10.8.0.0 255.255.255.0
route-gateway 10.8.0.1
crl-verify keys/foo/crl.pem
cipher AES-128-CBC
user nobody
group nogroup
status servers/server1/logs/openvpn-status.log
log-append servers/server1/logs/openvpn.log
verb 3
mute 20
max-clients 20
management 127.0.0.1 51194
keepalive 10 120
client-config-dir /etc/openvpn/servers/server1/ccd
tls-server
client-to-client
comp-lzo
persist-key
persist-tun
ccd-exclusive
push "route 172.16.1.0 255.255.255.0"
route 172.16.101.0 255.255.255.0

That TAP configuration was the same as my TUN configuration (not shown) except that I used “dev tap0” instead of “dev tun” and I had to add “route-gateway 10.8.0.1” directive due to error message I got about missing gateway.

After starting up both sides of the VPNs with the above settings, here are the routes I got. First the client routes on Zeroshell:

root@zeroshell openvpn> route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.101.0 * 255.255.255.0 U 0 0 0 ETH00
10.8.0.0 * 255.255.255.0 U 0 0 0 VPN00
172.16.1.0 10.8.0.1 255.255.255.0 UG 0 0 0 VPN00
default bilbo.lan 0.0.0.0 UG 0 0 0 ETH00

Now the server routes on Ubuntu:

jkelly@vpn1:/etc/openvpn$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.101.0 10.8.0.1 255.255.255.0 UG 0 0 0 tap0
10.8.0.0 * 255.255.255.0 U 0 0 0 tap0
172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
default veeger 0.0.0.0 UG 100 0 0 eth0

From the client I could ping server’s TAP device address (10.8.0.1), server’s LAN address (172.16.1.11) and a computer on the server’s LAN (e.g. 172.16.1.1). This is good!

From server I could ping client’s TAP device address (10.8.0.2) and client’s LAN address (172.16.101.77), BUT I could not ping any other computer on the client’s LAN (e.g. 172.16.101.1). For those 172.16.101.0/24 addresses, I got this error:

jkelly@vpn1:/etc/openvpn$ ping 172.16.101.1
PING 172.16.101.1 (172.16.101.1) 56(84) bytes of data.
From 10.8.0.1 icmp_seq=1 Destination Host Unreachable

Running tcpdump showed me the reason:

jkelly@vpn1:/etc/openvpn/servers/server1/logs$ sudo tcpdump -nn dst "172.16.101.1" -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
15:05:35.847010 arp who-has 172.16.101.1 tell 10.8.0.1

Well, I guess the arp is expected because this tunnel is at layer 2 and not layer 3. Anyway, I “fixed” this by running these commands on the server after the client is connected:

sudo ip route del 172.16.101.0/24 via 10.8.0.1 dev tap0
sudo ip route add 172.16.101.0/24 via 10.8.0.2 dev tap0

Notice that I had to delete the route that was added automatically when I brought up the server side VPN endpoint. The new route fixed my problem, forcing routing instead of arping.

Here is the new routing table, which is very similar to old one:

jkelly@vpn1:/etc/openvpn$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.101.0 10.8.0.2 255.255.255.0 UG 0 0 0 tap0
10.8.0.0 * 255.255.255.0 U 0 0 0 tap0
172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
default veeger 0.0.0.0 UG 100 0 0 eth0

Note that with dev TUN, I don’t need to run those routing commands at connection time. Instead, I just need to create a ccd file for the client on the server at configuration time. For example, here are the ccd file contents for this client on the server:

iroute 172.16.101.0 255.255.255.0
route 172.16.101.0 255.255.255.0

Unfortunately openvpn does not seem to allow iroute directives for TAP device, as shown by this portion of server log file for when the client connects:

Thu Aug 20 14:51:24 2009 x.x.x.x:1194 [client-jkelly5] Peer Connection Initiated with x.x.x.x:1194
Thu Aug 20 14:51:24 2009 client-jkelly5/x.x.x.x:1194 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/servers/server1/ccd/client-jkelly5
Thu Aug 20 14:51:24 2009 client-jkelly5/x.x.x.x:1194 Options error: option 'route' cannot be used in this context
Thu Aug 20 14:51:24 2009 client-jkelly5/x.x.x.x:1194 MULTI: --iroute options rejected for client-jkelly5/x.x.x.x:1194 -- iroute only works with tun-style tunnels
Thu Aug 20 14:51:25 2009 client-jkelly5/x.x.x.x:1194 PUSH: Received control message: 'PUSH_REQUEST'
Thu Aug 20 14:51:25 2009 client-jkelly5/x.x.x.x:1194 SENT CONTROL [client-jkelly5]: 'PUSH_REPLY,route 172.16.1.0 255.255.255.0,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0' (status=1)

So I guess I was somewhat successful in getting TAP device to work in routed mode. HOWEVER, I have concluded that routed mode is much easier to configure with a TUN device than with a TAP device.

Furthermore, almost all OpenVPN documentation, examples and tutorials seem to assume that you are going to use TUN in routed mode and TAP in bridging mode. Very few people are talking about TAP in routed mode. Note also that GUI configurators like the OpenVPN admin module for webmin force you to use bridging if you select the TAP device.

So again I respectfully request, can the Zeroshell GUI please be modified to allow the OPTION of using of TUN devices for LAN-to-LAN VPNs? I’m willing to donate money, testing time or both to get this feature implemented!