IPsec Tunnel Mode: Virtual Private Networks

 < Day Day Up > 



Instead of encrypting two hosts directly, you could use IPsec to just encrypt the gateways between the networks those hosts belong to, assuming that communication within those networks can be trusted. This would significantly reduce the encryption configuration setup, letting hosts from an entire network reach those of another network, using an intermediate secure IPsec connection between their gateways. For connections between gateways, transmissions sent through intervening routers can be tunneled. This is known as the tunnel mode for IPsec, which is used to implement virtual private networks (VPNs). Encrypted transmissions between gateways effectively implements a VPN, securing transmissions across a larger network from one local net to another.

To tunnel transmissions from a host through a gateway to a network, you would use the -m tunnel option. The IPsec connection would be between the two gateways. The following example is the security association on gateway 10.0.0.1 that encrypts transmissions from gateway 10.0.0.1 to gateway 10.0.23.5. The examples used here are for a gateway-to-gateway connection, set up as a direct connection between two hosts using manual keys.

add 10.0.0.1 10.0.23.5 esp 34501 -m tunnel -E 3des-cbc "secretkey";

The security policy on 10.0.0.1 then implements encryption for communication from one network to another using their respective gateways. The two networks are 192.168.0.0 and 192.168.1.0. Transmissions from hosts on the 192.168.0.0 network are encrypted by their gateway, 10.0.0.1, and are then sent to the gateway for the 192.168.1.0 network, 10.0.23.5, which then decrypts them.

spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/10.0.0.1- 10.0.23.5/require;

Notice that the gateway IP addresses are specified in the spdadd instruction's ipsec directive. The mode specified is the tunnel mode, rather than the transport mode.

ipsec esp/tunnel/10.0.0.1-10.0.23.5/require

The receiving gateway, 10.0.23.5, will have a corresponding security association and policy, as shown here. The policy is set for incoming transmissions. In both gateway configurations, other than specifying the tunnel option and using network addresses in the security policy, the security associations and policies are the same as those used for host-to-host connections.

add 10.0.0.1 10.0.23.5 esp 34501 -m tunnel -E 3des-cbc "secretkey";     spdadd 192.168.0.0/24 192.168.1.0/16 any -P in ipsec esp/tunnel/10.0.0.1- 10.0.23.5/require;

To set up full two-way communication, the two gateways would have corresponding security associations and policies to handle traffic in both directions. The following example is for the configuration on gateway 10.0.0.1 and handles two-way traffic to and from gateway 10.0.23.5. Gateway 10.0.23.5 would have a similar configuration:

add 10.0.0.1 10.0.23.5 esp 34501 -m tunnel -E 3des-cbc "secretkey"; add 10.0.23.5 10.0.03.1 esp 34501 -m tunnel -E 3des-cbc "secretkey";     spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/10.0.0.1- 10.0.23.5/require; 

spdadd 192.168.1.0/16 192.168.0.0/24 any -P in ipsec esp/tunnel/10.0.23.5- 10.0.0.1/require;

If you use racoon to configure gateway connections, you would only have to set the security policies on each gateway, letting the racoon server generate the needed security associations.



 < Day Day Up > 



Red Hat(c) The Complete Reference
Red Hat Enterprise Linux & Fedora Edition (DVD): The Complete Reference
ISBN: 0072230754
EAN: 2147483647
Year: 2004
Pages: 328

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net