VPN Madness
06/09/10 20:22 Filed in: Computing
The past few days (Labor Day Weekend), I’ve been learning about VPN’s - specifically, about IPsec VPNs using Openswan. A couple of years back, I bought a book by the Openswan developers about how to install, configure, setup, and use modern VPNs.
The experience has been a bit painful, to say the least. Part of the problem is that everything involved has been seeing a lot of active development; the NETKEY IPsec stack has seen a lot of development in the four years since the book was written. In the meantime, the ‘tried and true’ KLIPS IPsec stack is edging towards deprecation. I chose the NETKEY stack, as it is the ‘future’ direction. I’d like to be able to just let the VPN configuration sit...
I’ve learned a lot in the process - how to use OpenSSL to be your own CA for x.509 certificates, using x.509 with Openswan, and about some of the misconceptions I had about IPsec VPN’s.
Of the misconceptions, the first one was that a “straight” IPsec VPN could be setup to use DHCP to provide IP address assignment. Apparently, I was wrong - there were hopes that other mechanisms (XAUTH, IKE2) would address the issue. However, the industry (driven by Microsoft) moved from a straight IPsec implementation to using IPsec to tunnel a PPP connection. Then a normal PPP server can add additional (superfluous?) authentication, but also adds some features like IP address assignment, as well as DNS, WINS, and a few others.
It’s funny - I remember reading about how PPTP (Microsoft’s first VPN protocol) is considered fatally flawed... and the only real difference with PPTP and L2TP with IPsec is that IPsec is used to transport the PPP data, where PPTP did its own encryption...
The problem is with L2TP, you don’t get ‘perfect forward secrecy’ - because the encryption keys don’t get generated for a certain period of time, and then discarded afterwards There are other issues; but for the most part, it seems that a pure IPsec implementation would be a more secure solution - certainly more elegant - fewer daemons, a more ‘pure’ model, and fewer things to go wrong.
Still, L2TP is an IETF standard, so it’s not going away. And one of the book’s authors (also an openswan dev, for that matter) told me that there was XAUTH which tried to address DHCP-like assignment. Dhcp-over-ipsec didn’t really make it either. And in absence of anything else that worked, the world moved to L2TP, as it’s what’s available “out of the box” with Windows and Mac. When I asked if L2TP was the only way to do auto-IP address assignment, DNS servers, etc - the reply was terse: “Yes.”
Since the book also talked about “Opportunistic Encryption” - where IPsec VPN’s between two points auto-negotiate and create an encrypted tunnel for communication, I asked about how much OE is actually used. Sadly, the reply was that it’s a dead end until DNSSEC starts to be used - and DNS stores the certificates required to make OE happen automatically. He also mentioned a new NAT-NAT method would likely be required, but I think that simply won’t happen - I’ll bet IPv6 is widely deployed before new NAT-NAT stuff gets sorted out. Either way, he recommended not using OE right now.
And as it stands, I don’t have it working yet. I appear to have the IPsec part working properly. The l2tp part... not so much. I’m not sure if it’s a problem with the xl2tpd daemon (or its config), my firewall, or anything else at this point. I’ll post how I did everything; the config isn’t that hard, and it seems I’ve done as much wrong as was possible before getting anything right. Still... I’m hoping to have a full l2tp VPN by the end of the week.
I’m doing this for all of the clients I have trying to connect to my network. Like me... and... myself... and I. I suppose I’m doing it more for the enjoyment of solving the puzzle and learning than for any practical application.
Otherwise, it’s interesting to see just how much poking the VPN gets from unauthorized users - and watch as they are denied access for various reasons - but never getting to the point where a certificate is transferred. I’m not certain exactly how IPsec does its authorization yet; but it seems that the feelers don’t get past the first phase of negotiation - let alone the second phase where they would need a valid RSA key with a proper signed certificate... Still, I’m hoping that Openswan has a security record as good as (or better than) openssh. I can’t help but wonder how the track record of the two compare...
The experience has been a bit painful, to say the least. Part of the problem is that everything involved has been seeing a lot of active development; the NETKEY IPsec stack has seen a lot of development in the four years since the book was written. In the meantime, the ‘tried and true’ KLIPS IPsec stack is edging towards deprecation. I chose the NETKEY stack, as it is the ‘future’ direction. I’d like to be able to just let the VPN configuration sit...
I’ve learned a lot in the process - how to use OpenSSL to be your own CA for x.509 certificates, using x.509 with Openswan, and about some of the misconceptions I had about IPsec VPN’s.
Of the misconceptions, the first one was that a “straight” IPsec VPN could be setup to use DHCP to provide IP address assignment. Apparently, I was wrong - there were hopes that other mechanisms (XAUTH, IKE2) would address the issue. However, the industry (driven by Microsoft) moved from a straight IPsec implementation to using IPsec to tunnel a PPP connection. Then a normal PPP server can add additional (superfluous?) authentication, but also adds some features like IP address assignment, as well as DNS, WINS, and a few others.
It’s funny - I remember reading about how PPTP (Microsoft’s first VPN protocol) is considered fatally flawed... and the only real difference with PPTP and L2TP with IPsec is that IPsec is used to transport the PPP data, where PPTP did its own encryption...
The problem is with L2TP, you don’t get ‘perfect forward secrecy’ - because the encryption keys don’t get generated for a certain period of time, and then discarded afterwards There are other issues; but for the most part, it seems that a pure IPsec implementation would be a more secure solution - certainly more elegant - fewer daemons, a more ‘pure’ model, and fewer things to go wrong.
Still, L2TP is an IETF standard, so it’s not going away. And one of the book’s authors (also an openswan dev, for that matter) told me that there was XAUTH which tried to address DHCP-like assignment. Dhcp-over-ipsec didn’t really make it either. And in absence of anything else that worked, the world moved to L2TP, as it’s what’s available “out of the box” with Windows and Mac. When I asked if L2TP was the only way to do auto-IP address assignment, DNS servers, etc - the reply was terse: “Yes.”
Since the book also talked about “Opportunistic Encryption” - where IPsec VPN’s between two points auto-negotiate and create an encrypted tunnel for communication, I asked about how much OE is actually used. Sadly, the reply was that it’s a dead end until DNSSEC starts to be used - and DNS stores the certificates required to make OE happen automatically. He also mentioned a new NAT-NAT method would likely be required, but I think that simply won’t happen - I’ll bet IPv6 is widely deployed before new NAT-NAT stuff gets sorted out. Either way, he recommended not using OE right now.
And as it stands, I don’t have it working yet. I appear to have the IPsec part working properly. The l2tp part... not so much. I’m not sure if it’s a problem with the xl2tpd daemon (or its config), my firewall, or anything else at this point. I’ll post how I did everything; the config isn’t that hard, and it seems I’ve done as much wrong as was possible before getting anything right. Still... I’m hoping to have a full l2tp VPN by the end of the week.
I’m doing this for all of the clients I have trying to connect to my network. Like me... and... myself... and I. I suppose I’m doing it more for the enjoyment of solving the puzzle and learning than for any practical application.
Otherwise, it’s interesting to see just how much poking the VPN gets from unauthorized users - and watch as they are denied access for various reasons - but never getting to the point where a certificate is transferred. I’m not certain exactly how IPsec does its authorization yet; but it seems that the feelers don’t get past the first phase of negotiation - let alone the second phase where they would need a valid RSA key with a proper signed certificate... Still, I’m hoping that Openswan has a security record as good as (or better than) openssh. I can’t help but wonder how the track record of the two compare...