IPSec VPN concepts - confused
my goal is to approach VPN's creation.
I'm trying to create a IPSec VPN tunnel between my router (Netgear DSG2200 with IPSec built-in function) and a Debian server using Openswan, but I'm sure I'm missing something. I read lots of articles and how-tos as well as threads on this forum but that pretty much added confusion to confusion.
I'm trying IPSec because the current net appliances I own support it and because it allows key type auth via ike - without using certificates.
The scenario is this: I want to be able to see the debian server as part of my local network (which is 192.168.1.0/24 - the router is .254 - let's say I want the external server to be .253 for example). The debian server only has a public IP.
Question is, can this be done? And if yes, what do I need? I get I have to have ipsec up and running on the debian server (which in this example will be a client, since the VPN server in the lan is my router) - and it's what I'm trying to configure now. But I wanted a hint from someone expert that I'm not wasting my time because I'm missing something concept-wise.
Thanks to all who will be kind enough to enlighten me.
IPsec itself only provides the security. It is not encapsulation (except what is needed to just encrypt packets). It is not a tunnel. You can communicate directly to the server securely via its public IP. Its design is intended as end-to-end security, not VPN.
But IPsec also allows control over what communication is, and is not, encrypted. You could set up IPsec on your desktop and on your server and configure it to encrypt your HTTP communications. Then when you access your web server, it will be encrypted even though HTTP itself is not. But unlike HTTPS, you won't see the SSL/TLS certificates. You depend on the IPsec certificates or shared keys to keep you safe from a MitM attack.
If you enable IPsec for all communications, then everyone else can use IPsec to communicate with your server, too. That doesn't make your server any safer from attacks. It just hides what all those users might be doing from any sniffers along the way. Nor does it endanger your server because even though public users can communicate in an encrypted manner, they can only communicate to what services you allow them to access (hint: don't allow public access to set up a tunnel or you might find some hacker in your home LAN via your server).
Some networks don't actually require a tunnel, per se, but just require encrypted communication. IPsec alone will do this job for communications that cannot otherwise be secured. Many networks are set up with security like this without it being a tunnel. It still sometimes gets mislabeled as a "VPN".
But you want your server to be tunneled back home and have a local IP address. That's just a tunneling setup with IPsec configured on each end to encrypt the tunnel traffic. The endpoint at home could be any machine that can do the tunnel, not just the router. But the router is certainly convenient if you want to do that there. The configuration tools usually set up both aspects of this (if they are IPsec aware).
You still have tunneling detail choices. You could choose to tunnel at the IP packet layer in which case your router at home has to fake the server being local by using proxy ARP or some other faking of the ARP address. The other option in tunneling is to tunnel the ethernet frames. In this case the ARP queries other machines on your home LAN do will be all passed to the server which could answer the queries for its IP address.
I've never worked with Openswan, so I can't tell you how that is done, specifically. I also have not worked with the Netgear DSG2200 router.
|All times are GMT -5. The time now is 12:53 AM.|