"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):
Data
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):
Data 3 FreeBSD gw 1 WAN 192.168.51.1 2 WAN 192.168.52.1 sysctl: net.inet.ip.forwarding: 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:
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 abug is a “feature”.
PS I publish it solely because I want to warn those who use these routers in production.
We put together a simple stand - 1 Draytek gateway, 1 VPN server on a fray (connected directly):
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):
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 lettersdate 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
PS I publish it solely because I want to warn those who use these routers in production.