"Feature" in IPSEC implementation of VPN routers Draytek

    Draytek is a relatively new company in the Russian segment that occupies the niche of inexpensive compact All-in-one routers. Here and here you can read an overview of the two most popular router models of this company of the 2820 and 2910 series (which, by the way, are positioned as a “security firewall”). Among the other advantages of these routers, the most delicious is the hardware support for encryption (AES / DES / 3DES) and authentication (MD5, SHA-1), so it’s possible to configure a VPN between points and sleep peacefully. But not everything is as simple as it seems.

    We put together a simple stand - 1 Draytek gateway, 1 VPN server on a fray (connected directly):
    image
    Data
    Draytek 2910:
    LAN: 192.168.9.1/24
    WAN: 99.99.99.99/24
    GW: 99.99.99.100 (обязательно)
    FreeBSD:
    LAN: 192.168.3.32/24
    WAN: 99.99.99.100/24




    As a server, I took FreeBSD with security / racoon2. We raise the VPN, after some time we lower spmd (turn off racoon2 on the fail), ping the internal address of the fail (after running tcpdump) from Draytek. Pings! Oh hell, how could that be?

    We simulate an ideal situation - 2 routers from the manufacturer (2910 and 2820), a gateway in the middle (the same fray with tcpdump):
    image

    Data 3 FreeBSD gw 1 WAN 192.168.51.1 2 WAN 192.168.52.1 sysctl: net.inet.ip.forwarding: 1
    1 Draytek 2910
    LAN: 192.168.9.1/24
    WAN: 192.168.51.2
    GW: 192.168.51.1
    2 Draytek 2820
    LAN: 192.168.10.1/24
    WAN: 192.168.52.2
    GW: 192.168.52.1








    When you disconnect the VPN channel (let's say the provider’s network fell) on 2 routers, 1 router deletes the encrypted tunnel and ... starts broadcasting packet addresses to the external interface!

    Draytek Vigor 2910VG and 2820Vn were tested, the behavior is the same. I think all routers of these series are affected by this vulnerability - after the tunnel is broken, the translation of outgoing packet addresses begins, which must be encrypted .
    Do not look at only ICMP traffic in the video, all IP traffic is broadcast, this can be seen in the http packets at the end of the video (laptop for draytek 2910 [ip address 192.168.9.2]).

    Manufacturer warned. Correspondence with him:
    anyone support@draytek.com
    date Aug 27, 2010 6:05 pm
    topic bug in your routers


    I found bug in your routers (I think this bug present in other xx routers too).
    I create test configuration:
    192.168.3.0/24 | 192.168.1.10 (freebsd) - 192.168.1.2 (router) | 192.168.9.0/24
    in left side I use freebsd os with racoon2 port (ipsec-tools too)
    Bug is very serious:
    when I create vpn tunnel with ESP encryption between hosts and after some time stop spmd (on freebsd), router clear his policies (connection management page is blank) and start NAT 192.168.3.0/24 net traffic to freebsd external interface. All NAT'ed traffic is unencrypted!

    You can download video from xxx. I attach router (admin without password) and racoon2 config files.

    If you don't answer to this letter until monday, I publish it in bugtrackers.
    some letters
    date September 2, 2010 8:20
    topic Re: [Ticket # 2010082810002448] Fwd: bug in your routers

    Dear Sir,

    Thank you for the information.
    Although the current mechanism may violate the standard, it provides flexibility
    for many applications. For example when vpn is up, a public server is accessed
    through a vpn tunnel and routed to the Internet by remote vpn gateway. When vpn
    is down, the same public server can be accessed directly from local wan
    connection. This kind of usage is useful in VoIP implementation.

    to whom Draytek Support
    date September 2, 2010 17:15
    topic Re: [Ticket # 2010082810002448] Fwd: bug in your routers


    and how disable it?
    September 3, 2010, 7:31 a.m.
    topic Re: [Ticket # 2010082810002448] Fwd: bug in your routers


    Dear Sir,
    Sorry this mechanism cannot be changed.

    These are the feints with my ears to the detriment of standards. And such feints, as you know, do not pass without a trace. IPSEC is a very serious standard that guarantees the security of the transmitted information, and here such a bug is a “feature”.

    PS I publish it solely because I want to warn those who use these routers in production.

    Also popular now: