From aaa0331ecf95ced1e913ac9be50168cf0e7cbb82 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Tue, 30 Jan 2007 12:21:07 +0000 Subject: [svn-upgrade] Integrating new upstream version, strongswan (2.8.2) --- doc/src/config.html | 394 ---------------------------------------------------- 1 file changed, 394 deletions(-) delete mode 100644 doc/src/config.html (limited to 'doc/src/config.html') diff --git a/doc/src/config.html b/doc/src/config.html deleted file mode 100644 index b98e452db..000000000 --- a/doc/src/config.html +++ /dev/null @@ -1,394 +0,0 @@ - - - - FreeS/WAN configuration - - - - -

How to configure FreeS/WAN

- -

This page will teach you how to configure a simple network-to-network -link or a Road Warrior connection between two Linux FreeS/WAN boxes. -

- -

Requirements

- -

To configure the network-to-network connection you must have:

two Linux gateways with static IPs
a network behind each gate. Networks must have non-overlapping IP ranges.
Linux FreeS/WAN installed - on both gateways
tcpdump on the local gate, - to test the connection

For the Road Warrior you need:

one Linux box with a static IP
a Linux laptop with a dynamic IP
Linux FreeS/WAN installed on both
for testing, tcpdump on your gateway or laptop

- -

If both IPs are dynamic, your situation is a bit trickier. Your best bet -is a variation on the Road Warrior, as described -in this mailing list message. - -

Net-to-Net connection

- - -

Gather information

- -

For each gateway, compile the following information:

gateway IP
IP range of the subnet you will be protecting. This doesn't have to - be your whole physical subnet.
a name by which that gateway can identify itself for IPsec -negotiations. Its form is a Fully Qualified Domain Name preceded by -an @ sign, ie. @xy.example.com. -
It does not need to be within a domain that you own. It can be a made-up -name.

- - -

Get your leftrsasigkey

On your local Linux FreeS/WAN gateway, print your IPsec public key:

    ipsec showhostkey --left

The output should look like this (with the key shortened for easy - reading):

    # RSA 2048 bits   xy.example.com   Fri Apr 26 15:01:41 2002
-    leftrsasigkey=0sAQOnwiBPt...

- -

Don't have a key? Use -ipsec newhostkey -to create one. - -

...and your rightrsasigkey

Get a console on the remote side:

    ssh2 ab.example.com

In that window, type:

    ipsec showhostkey --right

You'll see something like:

    # RSA 2192 bits   ab.example.com   Thu May 16 15:26:20 2002
-    rightrsasigkey=0sAQOqH55O...

- -

Edit `/etc/ipsec.conf`

- -

Back on the local gate, copy our template to /etc/ipsec.conf. -(on Mandrake, /etc/freeswan/ipsec.conf). -Substitute the information you've gathered for our example data.

conn net-to-net
-    left=192.0.2.2                 # Local vitals
-    leftsubnet=192.0.2.128/29      # 
-    leftid=@xy.example.com         #   
-    leftrsasigkey=0s1LgR7/oUM...   #
-    leftnexthop=%defaultroute      # correct in many situations 
-    right=192.0.2.9                # Remote vitals
-    rightsubnet=10.0.0.0/24        #
-    rightid=@ab.example.com        # 
-    rightrsasigkey=0sAQOqH55O...   #
-    rightnexthop=%defaultroute     # correct in many situations
-    auto=add                       # authorizes but doesn't start this 
-                                   # connection at startup

- -

-"Left" and "right" should represent the machines that have FreeS/WAN installed -on them, and "leftsubnet" and "rightsubnet" machines that are being protected. -/32 is assumed for left/right and left/rightsubnet parameters. -

- -

Copy conn net-to-net to the remote-side /etc/ipsec.conf. -If you've made no other modifications to either ipsec.conf, -simply:

    scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf

- -

Start your connection

- -

Locally, type:

    ipsec auto --up net-to-net

- -

You should see:

    104 "net-net" #223: STATE_MAIN_I1: initiate
-    106 "net-net" #223: STATE_MAIN_I2: sent MI2, expecting MR2
-    108 "net-net" #223: STATE_MAIN_I3: sent MI3, expecting MR3
-    004 "net-net" #223: STATE_MAIN_I4: ISAKMP SA established
-    112 "net-net" #224: STATE_QUICK_I1: initiate
-    004 "net-net" #224: STATE_QUICK_I2: sent QI2, IPsec SA established

- -

The important thing is IPsec SA established. If you're -unsuccessful, see our -troubleshooting tips.

- - -

Do not MASQ or NAT packets to be tunneled

- -

If you are using IP masquerade or -Network Address Translation (NAT) -on either gateway, -you must now exempt the packets you wish to tunnel from this treatment. -For example, if you have a rule like:

- -

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
-

- -

change it to something like:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE

- -

This may be necessary on both gateways.

- - -

Test your connection

- -

Sit at one of your local subnet nodes (not the gateway), and ping a subnet -node on the other (again, not the gateway).

- -

    ping fileserver.toledo.example.com

- -

While still pinging, go to the local gateway and snoop your outgoing -interface, for example:

    tcpdump -i ppp0

You want to see ESP (Encapsulating Security Payload) packets moving -back and forth between the two gateways at the same frequency as -your pings:

    19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
-    19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)

- -

If you see this, congratulations are in order! You have a tunnel which -will protect any IP data from one subnet -to the other, as it passes between the two gates. -If not, go and troubleshoot.

- -

Note: your new tunnel protects only net-net traffic, not -gateway-gateway, or gateway-subnet. If you need this (for example, if -machines on one net need to securely contact a fileserver on the -IPsec gateway), you'll need to create -extra connections.

- - -

Finishing touches

- -

Now that your connection works, name it something sensible, like:

conn winstonnet-toledonet

To have the tunnel come up on-boot, replace

    auto=add

with:

    auto=start

Copy these changes to the other side, for example:

    scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf

Enjoy!

- - - -

Road Warrior Configuration

- -

Gather information

- -

You'll need to know:

the gateway's static IP
the IP range of the subnet behind that gateway
a name by which each side can identify itself for IPsec -negotiations. Its form is a Fully Qualified Domain Name preceded by -an @ sign, ie. @road.example.com. -
It does not need to be within a domain that you own. It can be a made-up -name.

- -

Get your leftrsasigkey...

On your laptop, print your IPsec public key:

    ipsec showhostkey --left

The output should look like this (with the key shortened for easy - reading):

    # RSA 2192 bits   road.example.com   Sun Jun  9 02:45:02 2002
-    leftrsasigkey=0sAQPIPN9uI...

- -

Don't have a key? See -these instructions. - - -

...and your rightrsasigkey

Get a console on the gateway:

    ssh2 xy.example.com

View the gateway's public key with:

    ipsec showhostkey --right

This will yield something like

    # RSA 2048 bits   xy.example.com   Fri Apr 26 15:01:41 2002
-    rightrsasigkey=0sAQOnwiBPt...

- - -

Customize `/etc/ipsec.conf`

- -

On your laptop, copy this template to /etc/ipsec.conf. -(on Mandrake, /etc/freeswan/ipsec.conf). -Substitute the information you've gathered for our example data.

conn road
-    left=%defaultroute             # Picks up our dynamic IP 
-    leftnexthop=%defaultroute      # 
-    leftid=@road.example.com       # Local information
-    leftrsasigkey=0sAQPIPN9uI...   #
-    right=192.0.2.10               # Remote information
-    rightsubnet=10.0.0.0/24        #
-    rightid=@xy.example.com        # 
-    rightrsasigkey=0sAQOnwiBPt...  #
-    auto=add                       # authorizes but doesn't start this
-                                   # connection at startup

- -

The template for the gateway is different. Notice how it -reverses left and right, in keeping with our -convention that Left is Local, -Right Remote. Be sure to switch your -rsasigkeys in keeping with this.

- -

    ssh2 xy.example.com
-    vi /etc/ipsec.conf

- -

and add:

- -

conn road
-    left=192.0.2.2                 # Gateway's information
-    leftid=@xy.example.com         #
-    leftsubnet=192.0.2.128/29      #
-    leftrsasigkey=0sAQOnwiBPt...   #
-    rightnexthop=%defaultroute     # correct in many situations
-    right=%any                     # Wildcard: we don't know the laptop's IP
-    rightid=@road.example.com      #
-    rightrsasigkey=0sAQPIPN9uI...  #
-    auto=add                       # authorizes but doesn't start this
-                                   # connection at startup

- - - -

Start your connection

- -

You must start the connection from the Road Warrior side. On your laptop, -type:

    ipsec auto --start net-to-net

- -

You should see:

104 "net-net" #223: STATE_MAIN_I1: initiate
-106 "road" #301: STATE_MAIN_I2: sent MI2, expecting MR2
-108 "road" #301: STATE_MAIN_I3: sent MI3, expecting MR3
-004 "road" #301: STATE_MAIN_I4: ISAKMP SA established
-112 "road" #302: STATE_QUICK_I1: initiate
-004 "road" #302: STATE_QUICK_I2: sent QI2, IPsec SA established

- -

Look for IPsec SA established. If you're -unsuccessful, see our -troubleshooting tips.

- - - -

Do not MASQ or NAT packets to be tunneled

- -

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
-

- -

change it to something like:

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE

- - -

Test your connection

- -

From your laptop, ping a subnet node behind the remote gateway. Do not -choose the gateway itself for this test.

- -

    ping ns.winston.example.com

- -

Snoop the packets exiting the laptop, with a command like:

    tcpdump -i wlan0

You have success if you see (Encapsulating Security Payload) packets -travelling in both directions:

- -

    19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
-    19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)

- - -

If you do, great! Traffic between your Road Warrior and the net -behind your gateway is protected. -If not, see our -troubleshooting hints.

- -

Your new tunnel protects only traffic addressed to the net, not to -the IPsec gateway itself. If you need the latter, you'll want to make an -extra tunnel..

- -

Finishing touches

- -

On both ends, name your connection wisely, like:

conn mike-to-office

On the laptop only, replace

    auto=add

with:

    auto=start

so that you'll be connected on-boot.

Happy telecommuting!

- -

Multiple Road Warriors

- -

If you're using RSA keys, as we did in this example, you can add -as many Road Warriors as you like. The left/rightid -parameter lets Linux FreeS/WAN distinguish between multiple Road Warrior -peers, each with its own public key.

- -

The situation is different for shared secrets (PSK). During a -PSK negotiation, ID information is not available at the time Pluto -is trying to determine which secret to use, so, effectively, you can -only define one Roadwarrior connection. All your PSK road warriors -must therefore share one secret.

- - -

What next?

- -

Using the principles illustrated here, you can try variations such as: -

a telecommuter with a static IP
a road warrior with a subnet behind it

Or, look at some of our more complex configuration examples..

- - -- cgit v1.2.3

How to configure FreeS/WAN

Requirements

Net-to-Net connection

Gather information

Get your leftrsasigkey

...and your rightrsasigkey

Edit /etc/ipsec.conf

Start your connection

Do not MASQ or NAT packets to be tunneled

Test your connection

Finishing touches

Road Warrior Configuration

Gather information

Get your leftrsasigkey...

...and your rightrsasigkey

Customize /etc/ipsec.conf

Start your connection

Do not MASQ or NAT packets to be tunneled

Test your connection

Finishing touches

Multiple Road Warriors

What next?

Edit `/etc/ipsec.conf`

Customize `/etc/ipsec.conf`