Community Owned Information Network

Welcome to the CSIR Meraka Institute's "COIN" Blog

Wednesday, August 31, 2005

Establishing IPsec tunnel/connection between FreeBSD and Linux (openswan IPsec Cisco WRT54G Router)

Establishing IPsec tunnel/connection between FreeBSD and Linux (openswan IPsec Cisco WRT54G Router)

Below is a simple setup demonstrating steps to establish an IPsec connection/tunnel between two machines one running Ipsec/racoon (on FreeBSD) and the other running openswan Ipsec (on WRT54G running Linux) using pre-shared key: This IPsec setup example shows how to control the Private LAN_A (146.64.0.0) network access.



.........(INTERNET)

.........|

.........|

..| FreeBSD | ......10.50.1.3..............................10.50.1.80| Openswan IPsec|

.| Router_A |<========> (“NETWORK”)<=======>| Router_B |

.| 146.64.17.1 |................................................................| 10.1.13.1 |

............ ||.........................................................................||

...Private LAN_A....................................................PPrivate LAN_B

...........|.......................................................................................|...........
....Client_A (146.64.17.12) ..................................Client_B (10.1.13.130)



NOTE: Before running racoon/ipsec and openswan ipsec, ensure that all nodes can successfully reach (ping) each other.



INSTALLING OPENSWAN ON WRT54G

To install, add the following to /etc/ipkg.conf:

src openswan ftp://ftp.openswan.org/openswan/binaries/openwrt/buildroot-20040509/ipkg/

and then run:

ipkg update

ipkg install gmp mawk openswan-module openswan

NOTE: Since /etc/ipkg.conf would normally be a link to the file in /rom directory; You can simple delete the link, and then copy the file over.




CONFIGURATION (Router_A IPsec)


There are three (3) configuration files on Router_A that needs to be edited: ipsec.conf (found in /etc on FreeBSD), psk.conf.(found in /usr/local/etc/racoon/ on FreeBSD) and racoon.conf.(found in /usr/local/etc/racoon/ on FreeBSD).

Add the following two lines in ipsec.conf: (This file defines the ends points of the tunnel to be established. There’d be two lines for each LAN_B client )

spdadd 146.64.0.0/16 10.1.13.0/24 any -P out ipsec esp/tunnel/10.50.1.3-10.50.1.80/require;

spdadd 10.1.13.0/24 146.64.0.0/16 any -P in ipsec esp/tunnel/10.50.1.80-10.50.1.3/require;

Roughly; the first line says “traffic coming from 146.64.0.0 network destined for 10.1.13.0 network must be transported via an IPsec tunnel with local endpoint 10.50.1.3 and far endpoint 10.50.1.80”.

The second line says “traffic coming from 10.1.13.0 network destined for 146.64.0.0 network must/would use an IPsec tunnel with a far endpoint 10.50.1.80 and local endpoint 10.50.1.3”.

Add the following line to psk.conf (This file defines the pre-shared key to be used between Router_A and Router_B).

10.50.1.80 presharedkey

NOTE: Comments must be on a different line to the pre-shared key entry, otherwise the comments are interpreted as part of the pre-shared key.

Add the following lines to racoon.conf

path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

remote anonymous

{

# exchange_mode aggressive,main ;

exchange_mode main ;

lifetime time 24 hour ;

proposal {

encryption_algorithm 3des ;

hash_algorithm sha1;

authentication_method pre_shared_key ;

dh_group 2 ;

}

}

sainfo anonymous

{

lifetime time 12 hour ;

encryption_algorithm 3des, blowfish, des, rijndael ;

authentication_algorithm hmac_sha1, hmac_md5 ;

compression_algorithm deflate ;

}

IMPORTANT: The IPsec version (2.3.1) used in this example did not seem to support “aggressive” exchange_mode hence “main” is specified. However, it is possible to include more than mode by separating them with comma; i.e.

exchange_mode aggressive, main ;

Both ways (specifying one or more modes) works! Further other lines with more than one values separated by comma may contain only one value as described for exchange_mode above.



CONFIGURATION (Openswan IPsec, Router_B)

There are two (2) files on Router_B that needs editing: ipsec.conf (found in /etc on Linux) and ipsec.secrets (found in /etc on Linux).

Add the following line in ipsec.secrets: (This file defines the ends points of the tunnel to be established and also the pre-shared key to be used)

10.50.1.3 10.50.1.80: PSK “presharedkey”

NOTE: 1. Place the string after PSK in quotes if it does not start with 0x (as in a hexadecimal number), otherwise openswan will complain.

2. The string after PSK must be the same as that specified in psk.conf on Router_A.

Add the following lines in ipsec.conf: (This file defines among other things, the network to be protected, authentication methods, type of connection, etc.)

config setup

interfaces="ipsec0=eth1"

klipsdebug=none

plutodebug=none

uniqueids=yes

conn %default

keyingtries=0

authby=secret #rsasig

conn crypt

left=10.50.1.80

leftid=10.50.1.80

leftsubnet=10.1.13.1/24

right=10.50.1.3

rightid=10.50.1.3

rightsubnet=146.64.8.8/16

auto=start

type=tunnel

NOTE: The name of our connection is called “crypt”. Under “config setup”, the line interfaces=”ipsec0=eth1” must refer to a real interface (ifconfig will show available interfaces) and also must be the interface through which the data to be protected will travel, in case of more than one NIC. The line “auto=start” says, the connection “crypt” must be brought up when openswan ipsec starts up; to bring up the connection manually either comment out the line or specify “auto=ignore”. The explanation given for ipsec.conf on Router_A is pretty much the same as for Router_B.



STARTING UP IPsec and Racoon (FreeBSD).

At this point all machines are able to reach (ping) each other successfully. Next ensure ipsec and racoon are not running. On my machine I do:

verdi2istc#/etc/rc.d/ipsec stop

Clearing ipsec manual keys/policies.

to stop ipsec if it was already running; and do

verdi2istc# setkey -P -D

No SPD entries.

To ensure there are no IPsec SA/SP database entries; and next do

verdi2istc#killall racoon

to stop racoon.

Next issue

verdi2istc# /etc/rc.d/ipsec restart

to start ipsec, and to verify ipsec started successfully then do

verdi2istd# setkey -P -D

10.1.13.0/24[any] 146.64.0.0/16[any] any

in ipsec

esp/tunnel/10.50.1.80-10.50.1.3/require

created: Aug 30 09:27:39 2005 lastused: Aug 30 09:27:39 2005

lifetime: 0(s) validtime: 0(s)

spid=16531 seq=1 pid=583

refcnt=1

146.64.0.0/16[any] 10.1.13.0/24[any] any

out ipsec

esp/tunnel/10.50.1.3-10.50.1.80/require

created: Aug 30 09:27:39 2005 lastused: Aug 30 09:27:39 2005

lifetime: 0(s) validtime: 0(s)

spid=16530 seq=0 pid=583

refcnt=1

From Router_A, type either racoon (to run in the backgroung) or racoon –F

verdi2istd#racoon

or to fun in foreground type

verdi2istd#racoon -F -d

Foreground mode.

2005-08-30 09:51:59: INFO: main.c:172:main(): @(#)package version freebsd-20040818a

2005-08-30 09:51:59: INFO: main.c:174:main(): @(#)internal version 20001216 sakane@kame.net

2005-08-30 09:51:59: INFO: main.c:175:main(): @(#)This product linked OpenSSL 0.9.7d 17 Mar 2004 (http://www.openssl.org/)

2005-08-30 09:51:59: DEBUG: pfkey.c:434:pfkey_init(): call pfkey_send_register for AH

2005-08-30 09:51:59: DEBUG: pfkey.c:434:pfkey_init(): call pfkey_send_register for ESP

2005-08-30 09:51:59: DEBUG: pfkey.c:434:pfkey_init(): call pfkey_send_register for IPCOMP

2005-08-30 09:51:59: DEBUG: cftoken.l:578:yycf_set_buffer(): reading config file /usr/local/etc/racoon/racoon.conf

2005-08-30 09:51:59: DEBUG: pfkey.c:2379:pk_checkalg(): compression algorithm can not be checked because sadb message doesn't support it.

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: 10.50.1.3 (ath0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: fe80::202:6fff:fe21:2e71%ath0 (ath0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: 146.64.8.1 (sis0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: fe80::200:24ff:fec2:b684%sis0 (sis0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: 127.0.0.1 (lo0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: ::1 (lo0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:206:grab_myaddrs(): my interface: fe80::1%lo0 (lo0)

2005-08-30 09:51:59: DEBUG: grabmyaddr.c:474:autoconf_myaddrsport(): configuring default isakmp port.

2005-08-30 09:52:00: DEBUG: grabmyaddr.c:496:autoconf_myaddrsport(): 7 addrs are configured successfully

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): fe80::1%lo0[500] used as isakmp port (fd=5)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): ::1[500] used as isakmp port (fd=6)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): 127.0.0.1[500] used as isakmp port (fd=7)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): fe80::200:24ff:fec2:b684%sis0[500] used as isakmp port (fd=8)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): 146.64.8.1[500] used as isakmp port (fd=9)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): fe80::202:6fff:fe21:2e71%ath0[500] used as isakmp port (fd=10)

2005-08-30 09:52:00: INFO: isakmp.c:1368:isakmp_open(): 10.50.1.3[500] used as isakmp port (fd=11)

2005-08-30 09:52:00: DEBUG: pfkey.c:197:pfkey_handler(): get pfkey X_SPDDUMP message

2005-08-30 09:52:00: DEBUG: pfkey.c:197:pfkey_handler(): get pfkey X_SPDDUMP message

2005-08-30 09:52:00: DEBUG: policy.c:184:cmpspidxstrict(): sub:0xbfbfea30: 146.64.0.0/16[0] 10.1.13.0/24[0] proto=any dir=out

2005-08-30 09:52:00: DEBUG: policy.c:185:cmpspidxstrict(): db :0x809dc08: 10.1.13.0/24[0] 146.64.0.0/16[0] proto=any dir=in

The –d option is for debug, to see more output add extra –d.

IMPORTANT: At this point if all went well Client_A should not be reachable (try ping) from Router_B and Client_B; meaning private LAN_A is now protected. However, Router_A and Router_B should be able reach/see each other. Do not continue until this is accomplished.



STARTING UP OPENSWAN IPSEC

Now, on Router_B do:

root@Lawrence:/# ipsec setup restart

ipsec_setup: Stopping Openswan IPsec...

ipsec_setup: Starting Openswan IPsec 2.3.1...

verify that the IPsec tunnel has been established correctly by issuing:

root@Lawrence:/# ipsec whack --status

000 interface ipsec0/eth1 10.50.1.80

000 %myid = (none)

000 debug none

000

000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=64, keysizemin=168, keysizemax=168

000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=128, keysizemin=128, keysizemax=256

000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128

000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160

000

000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128

000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192

000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20

000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16

000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024

000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536

000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048

000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072

000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096

000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144

000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192

000

000 stats db_ops.c: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}

000

000 "crypt": 10.1.13.0/24===10.50.1.80...10.50.1.3===146.64.0.0/16; erouted; eroute owner: #2

000 "crypt": srcip=unset; dstip=unset

000 "crypt": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0

000 "crypt": policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 24,16; interface: eth1;

000 "crypt": newest ISAKMP SA: #1; newest IPsec SA: #2;

000 "crypt": IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024

000

000 #2: "crypt":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27961s; newest IPSEC; eroute owner

000 #2: "crypt" esp.2ec9213@10.50.1.3 esp.aa7dc439@10.50.1.80 tun.1002@10.50.1.3 tun.1001@10.50.1.80

000 #1: "crypt":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2625s; newest ISAKMP; nodpd

000

root@Lawrence:/#

At this point Client_A should be reachable by Client_B. On each/either Router do a tcpdump; and any packets with ESP indicates that the setup tunnel is currently handling data from the clients.

NOTE: ESP packets will only appear if there are packets from either client to the other client.



DEBUGGING (Openswan IPsec)

Earlier I showed how to stop a connection from being started up automatically by openswan. IPsec. So now with ipsec running but our connection “crypt” NOT up, we will debug the starting up of the connection (crypt). To debug the key exchange with racoon, first create a script with following content:

ipsec pluto --debug-all

ipsec whack \

--name crypt \

--tunnel \

--host 10.50.1.80 \

--nexthop 10.50.1.3 \

--client 10.1.13.1/24 \

--updown 'ipsec _updown' --id 10.50.1.80 \

--to \

--host 10.50.1.3 \

--client 146.64.8.1/16 \

--updown 'ipsec _updown' --id 10.50.1.3 \

--psk \

--esp 3des-md5,3des-sha1 \

--ike 3des-md5,3des-sha1 \

--encrypt

ipsec whack --listen

ipsec whack --route --name crypt

ipsec whack --initiate --name crypt

Running this script will show the various key exchange messages. The messages are pretty much clear to see what it’s happening.

Posted by lawrence at 1:37 PM 7 comments

Thursday, August 11, 2005

Setting up DHCP with OLSR

There have been so many misleading postings on this - I will finally set the record straight.

You will need to reserve a block of IP's for non OLSR wireless clients that want to connect onto the mesh network such as a laptop. Here is an example setup:

Wireless router 1:
Wireless IP: 10.51.1.13
LAN IP: 10.3.13.1
Subnet for Wireless DHCP clients: 10.51.1.64/28 (This would mean that 16 machines could potentially connect to this wireless router. The IP leases will be in the range from 10.51.1.64 to 10.51.1.79)

Wireless router 2:
Wireless IP: 10.51.1.14
LAN IP: 10.3.14.1
Subnet for Wireless DHCP clients : 10.51.1.80/28 (IP leases will be in the range from 10.51.1.80 to 10.51.1.93)

To set this up On Friefunk firmware
Wireless Router 1:
OLSR:
OLSR DHCP: 10.51.1.64/28

Wireless Router 2:
OLSR:
OLSR DHCP: 10.51.1.80/28


Most people gave strange values for OLSR DHCP in their postings the most common one was:
OLSR DHCP: 10.51.1.80/28, 255.255.255.240

The subnet mask after the comma (255.255.255.240) is an alternative to the slash format /28. Why does everyone have this reduntant subnet mask on their postings???
Posted by king david at 12:10 AM 0 comments

Monday, August 08, 2005

good info on checking linksys hardware version

Finally some good info about finding the version number from outside markings and using NVRAM settings - info from www.openwrt.org

Linksys WRT54G

  1. Hardware versions
      1. Identification by S/N
    1. WRT54G v1.0
    2. WRT54G v1.1
    3. WRT54G v2.0
    4. WRT54G v2.2
    5. WRT54G v3.0 & WRT54G v3.1
    6. WRT54G v4.00
  2. Table summary
  3. Hardware hacking

1. Hardware versions

There are currently seven versions of the WRT54G (v1.0, v1.1, v2.0, v2.2, v3.0, v3.1, v4.00). With the exception of v4.00 devices (it is currently marked as untested for White Russian RC1), the WRT54G units are supported by OpenWrt 1.0 (White Russian) and later. boot_wait is off by default on these routers, so you should turn it on. The version number is found on the label on the bottom of the front part of the case below the Linksys logo.

1.0.1. Identification by S/N

Useful for identifying shrinkwrapped units. The S/N can be found on the box, below the UPC barcode.

(!) Please contribute to this list. (!)

OpenWRT

Model

S/N

CVS

EXP

WRT54G v1.1

CDF20xxxxxxx

(./)

(./)

CDF30xxxxxxx

WRT54G v2

CDF50xxxxxxx

(./)

(./)

WRT54G v2.2

CDF70xxxxxxx

{X}

(./)

WRT54G v3

CDF80xxxxxxx

{X}

(./)

WRT54G v3.1 (AU?)

CDF90xxxxxxx

{X}

(./)

1.1. WRT54G v1.0

The WRT54G v1.0 is based on the Broadcom 4710 board. It has a 125MHz CPU, 4Mb flash and 16Mb SDRAM. The wireless NIC is a mini-PCI card. The switch is an ADM6996.

1.2. WRT54G v1.1

The WRT54G v1.1 is based on the Broadcom 4710 board. It has a 125MHz CPU, 4Mb flash and 16Mb SDRAM. The wireless NIC is soldered to the board. The switch is an ADM6996.

Hardware informations (nvram) : 

boardtype=bcm94710dev
1.3. WRT54G v2.0

The WRT54G v2.0 is based on the Broadcom 4712 board. It has a 200MHz CPU, 4Mb flash and 16Mb SDRAM. The wireless NIC is integrated to the board. The switch is an ADM6996.

Hardware informations (nvram) : 

boardtype=0x0101
boardflags=0x0188
1.4. WRT54G v2.2

The WRT54G v2.2 is based on the Broadcom 4712 board. It has a 200MHz CPU, 4Mb flash and 16Mb DDR-SDRAM. The wireless NIC is integrated to the board. The switch is a BCM5325.

Hardware informations (nvram) : 

boardtype=0x0708
boardflags=0x0118
1.5. WRT54G v3.0 & WRT54G v3.1

This unit is just like the V2.2 Except it has an extra reboot button on the left front panel behind a Cisco logo.

1.6. WRT54G v4.00

Please add information for this revision.

Hardware informations (nvram) : 

boardrev=0x10
boardtype=0x0708
boardflags2=0
boardflags=0x0118
boardnum=42

/!\ To take the front cover off of this unit you must first remove the small screws under the rubber covers of the front feet!

2. Table summary

how to get info :

* board info: nvram show | grep board | sort
* cpu model: cat /proc/cpuinfo | grep cpu

Model

boardrev

boardtype

boardflags

boardflags2

boardnum

wl0_corerev

cpu model

WRT54G v1.1

-

bcm94710dev

-

-

42

5

BCM4710 V0.0

WRT54G v2.0

-

0x0101

0x0188

-

-

-

BCM3302 V0.7

WRT54G v2.2

-

0x0708

0x0118

-

-

7

-

WRT54G v3.0

0x10

0x0708

0x0118

0

42

7

BCM3302 V0.7

WRT54G v3.1 (AU?)

0x10

0x0708

0x0118

0

42

7

BCM3302 V0.7

WRT54G v4.0

0x10

0x0708

0x0118

0

42

7

BCM3302 V0.7

WRT54GS v1.0

0x10

0x0101

0x0388

0

42

7

BCM3302 V0.7

WRT54GS v1.1

0x10

0x0708

0x0318

0

42

-

-

Buffalo WBR-54G

0x10

bcm94710ap

0x0188

2

42

-

-

Toshiba WRC1000

-

bcm94710r4

-

-

100

-

-

Buffalo WBR2-G54S

0x10

0x0101

0x0188

0

00

-

-

Asus WL-500G Deluxe

0x10

bcm95365r

-

-

45

5

BCM3302 V0.7

*other variables (nvram) of interest : boot_ver, pmon_ver, firmware_version, os_version

please complete this table. Look at this thread : [WWW] http://openwrt.org/forum/viewtopic.php?pid=8127#p8127 May be this table should move up to OpenWrtDocs/Hardware.

3. Hardware hacking

There are revision XH units of the WRT54G v2.0. These units have 32Mb of memory, but they are locked to 16Mb. You can unlock the remaining memory with changing some of the variables. Afterburner (aka. Speedbooster) mode can be enabled with some variables, too.

/!\ However, there are no guaranties, that these will work, and changing the memory configuration on a non-XH unit will give You a brick. Check the forums for more info.

If you have a look at the WRT54G v2.2 board, you can find on the left corner, near the power LED, an empty place for a 4 pins button. On the board it is printed as SW2. This is the second reset button you can find on WRT54G v3.0, except that it has not been soldered.
Posted by king david at 12:10 AM 0 comments
Subscribe to: Posts (Atom)