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

This topic contains 10 replies, has 0 voices, and was last updated by  cyboc 9 years, 8 months ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #41864

    cyboc
    Member

    From poking around the user interface, reading forum messages and reading the documentation, it appears that Zeroshell does NOT support creating a LAN-to-LAN (site-to-site) VPN with a tun device. In other words, a LAN-to-LAN VPN can only be created with a tap device.
    Can anyone confirm this?

    #48632

    cyboc
    Member

    I’ve done some reading on the Zeroshell site about the advantages of a layer 2 bridged VPN using the TAP device. I won’t repeat those advantages here but I will point the interested reader to the following pages:

    On the other hand, there are also advantages to using a layer 3 routed VPN using the TUN device. Here’s a quote from the OpenVPN HOWTO:

    Overall, routing is probably a better choice for most people, as it is more efficient and easier to set up (as far as the OpenVPN configuration itself) than bridging. Routing also provides a greater ability to selectively control access rights on a client-specific basis.

    I would recommend using routing unless you need a specific feature which requires bridging, such as:

    * the VPN needs to be able to handle non-IP protocols such as IPX,
    * you are running applications over the VPN which rely on network broadcasts (such as LAN games), or
    * you would like to allow browsing of Windows file shares across the VPN without setting up a Samba or WINS server.

    I don’t want to get into a religious debate about which device is better, TUN or TAP. My point is that since OpenVPN gives us the choice, Zeroshell should give us the same choice instead of restricting us to using only TAP for LAN-to-LAN VPNs. After all, this is why we all love free and open source software: it gives us choices that proprietary software take away from us.

    For my own situation, we currently have a routed LAN-to-LAN VPN using proprietary VPN devices. I want to switch to Zeroshell. I really do. However, the switch is not so easy because Zeroshell does not appear to support routed LAN-to-LAN VPNs. Please correct me if I am wrong about this.

    I’ll put my money where my mouth is. If Zeroshell makes a commitment to support routed LAN-to-LAN VPNs with a TUN device, I’ll gladly make some PayPal donations (although I’d rather buy some Zeroshell T-shirts, hehe).

    Anyway, I don’t want to anger Fulvio, I just want to raise a healthy debate. I think Zeroshell is well on the way to being a fantastic product! Keep up the good work, Fulvio. 😀

    #48633

    imported_fulvio
    Participant

    Let me to understand why you would prefer tun instead of tap devices. TAP devices are like virtual ethernet connections: you are free to bridge TAP device with other ethernet interfaces or just assign an IP address an route traffic across them.

    Regards
    Fulvio

    #48634

    cyboc
    Member

    Fulvio, thank you for your reply.

    @fulvio wrote:

    Let me to understand why you would prefer tun instead of tap devices.

    I wouldn’t say that I prefer one or the other. I would just like the choice of which one to use. As described in the OpenVPN documenation, in some circumstances, TAP might be better and in others TUN might be better.

    @fulvio wrote:

    you are free to bridge TAP device with other ethernet interfaces or just assign an IP address an route traffic across them.

    The “route traffic across them” idea sounds promising but I’m not quite sure what you mean. Perhaps if I describe my situation a little better, you can tell me if TAP will work without having to make lots of changes to our subnet addressing.

    I have a main office with subnet 172.16.1.0/24 and remote offices with subnets 172.16.2.0/24, 172.16.3.0/24 and 172.16.4.0/24. Following the examples in the OpenVPN howto, we have created an “experimental” routed layer 3 VPN with the tun device.

    The VPN endpoints used in the “experiment” were a combination of VMs running Ubuntu and WRT54GLs running Tomato. For production, we were hoping to use Alix or Soekris boxes running pfSense, Voyage Linux or perhaps Zeroshell.

    Now, as far as I know, if we were forced to use a TAP device on Zeroshell, we would have to make all computers run on 172.16.1.0/24 subnet or we would have to reduce the number of bits in the subnet mask so that all addresses are on same subnet (e.g. 172.16.0.0/16). Either way, I think it’s probably a hassle for us to make those changes. Correct me if I am wrong and there is a way making TAP work with our current subnets.

    #48635

    imported_fulvio
    Participant

    TAP devices works fine either in routed or bridged forwarding. Hence, you can use Zeroshell and continue to split your LAN in the subnets you described.

    Regards
    Fulvio

    #48636

    cyboc
    Member

    @fulvio wrote:

    TAP devices works fine either in routed or bridged forwarding. Hence, you can use Zeroshell and continue to split your LAN in the subnets you described.

    Are you sure? The reason I ask is because of what it says about this in the OpenVPN howto. If you scroll down to the section “Including multiple machines on the client side when using a bridged VPN (dev tap)”, you’ll find this:

    This requires a more complex setup (maybe not more complex in practice, but more complicated to explain in detail):

    * You must bridge the client TAP interface with the LAN-connected NIC on the client.
    * You must manually set the IP/netmask of the TAP interface on the client.
    * You must configure client-side machines to use an IP/netmask that is inside of the bridged subnet, possibly by querying a DHCP server on the OpenVPN server side of the VPN.

    Note that part that says “You must configure client-side machines to use an IP/netmask that is inside of the bridged subnet”. That seems to suggest that I can’t use TAP without rejigging my subnet addressing. If I’m wrong, could you please point me to some further reading about this? I could not find any documentation on the Zeroshell site about routing in the context of using the TAP device. My apologies if I’m very stupid.

    #48637

    imported_fulvio
    Participant

    What you quoted from the OpenVPN documentation is valid only if you use TAP interfaces in bridge mode. In your case, you must not bridge the VPN interface with an ethernet one. Instead, you have to assign the IP address to both the VPN interfaces and then just add the static routes to route your subnets across the VPN. You could also enable RIP v2 so the routing is automatically managed without adding static routes.
    This is exactly the same steps you need if you use TUN interfaces.

    Regards
    Fulvio

    #48638

    cyboc
    Member

    @fulvio wrote:

    What you quoted from the OpenVPN documentation is valid only if you use TAP interfaces in bridge mode.

    Ah, thank for clearing that up. I thought TAP did not allow routed mode but I stand corrected, as indicated by this quote from the OpenVPN FAQ:

    When you are bridging, you must always use –dev tap on both ends of the connection. If you are routing you can use either –dev tap or –dev tun, but you must use the same on both ends of the connection. –dev tun tends to be slightly more efficient for the routing case.

    Now I just need to figure out how to implement that solution. All of the examples I have seen so far are either routed TUN or bridged TAP. I’ll give it a try and report my experience back here.

    Regardless, is there any good reason why Zeroshell can’t give you the option of using TUN device for LAN-to-LAN? Are there plans to implement this?

    #48639

    imported_fulvio
    Participant

    TUN devices are just for point-to-point connections. In other word you can only route traffic across them. TAP ones are more flexible because manage the brodcast traffic and therefore are like Ethernet devices. This allowed me to manage the VPN interfaces as Ethernet ones, without any additional effort.

    The how-to valid to build a routed VPN by using TUN interfaces is also valid if you use TAP devices. Nothing changes.

    Regards
    Fulvio

    #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!

    #48641

    cyboc
    Member

    Until the Zeroshell GUI supports TUN device, one workaround I just tried that seems to work is putting this in the Parameters field in the GUI:

    --dev tun0 --dev-type tun

    That creates this command line:

    openvpn --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 --dev tun0 --dev-type tun --cipher AES-128-CBC --client --verb 3 --down /root/kerbynet.cgi/scripts/vpn_mii

    Note that the hard coded TAP device directives are still there (–dev VPN00 –dev-type tap) but they seem to get overidden by the later TUN device directives (–dev tun0 –dev-type tun).

    My initial tests seem to show this is working. That is, I can do all the pings shown in the previous post, without having to do extra routing commands.

    Running ifconfig shows that tun0 was successfully created. Unfortunately, the tap device VPN00 is still there. I’m not sure if that lingering TAP device could cause problems or not with things like QoS. Need to do further testing.

    So, this is a workaround but I’d still prefer TUN support in gui.

    #48642

    imported_fulvio
    Participant

    To make Zeroshell use tun devices instead of tap ones you should:

    cd /root/kerbynet.cgi/scripts
    grep -w tap *

    and for any lines the contains the word tap to change it with tun.

    To make permanent the changes, copy the modified files in the directory /Database and then create a pre-boot script (Setup->Startup/Cron) which copies them in /root/kerbynet.cgi/scripts

    Regards
    Fulvio

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.