Are there any plans to integrate IPsec into Openwrt ? It seems FreeSwan would be a good choice, because kernel 2.4.20 ist perfectly supported. Possibly a wrt54g version 2 is required because OpenSSL and FreeSwan need many space...

I would be curious if there would be enough CPU to do IPSEC. Maybe at low bandwidth but this thing only shows up with about 83 bogomips. I think you need at least 85 to do IPSEC. This is complete speculation on my part though, I don't have any facts or supporting data. On the other hand, it seems to do WEP pretty well so I dunno.

I read ipcop is using it in their LFS distro that runs on old "junk" PCs. Might be somthing to check out.

-Chris

Hi, I think WRT54g 2.0 is fast enough for IPsec. Super FreeSwan seems to be a reasonable solution, if it fits into wrts flash. Otherwise I would employ a NFS server ;-)

add to your ipkg:

src openswan ftp://ftp.openswan.org/openswan/binarie … 0509/ipkg/                                                                                             

run "ipkg update"
run "ipkg install mawk gmp openswan-module openswan"

OpenWRT/OpenSwan enabled WRT54G to run as 100$ IPsec gateway now :-) Speed is ok for 3 MBit/s DSL line. I will try it now with my existing OpenSwan config, which uses X509 certificates.

is that using DES ? I am waiting for 2.2 so I can use AES which should be faster.

If you look through the posts on this subject right here in this forum, you'd have seen the post about performance too (http://openwrt.org/forum/viewtopic.php?t=191). 3DES runs about 1.5mbps, AES about 2.6mbps. Fine for a not-too-broadband broadband connection, but pretty useless for high speed wireless.

So, in reponse to the original poster, yes it is possible to ipsec with your WRT54G. I'd recommend a v2.x, though an 1.x should work too. Browse through the forum for lots more info on this subject, plenty has been said (and done) in this area.

These are a bit old, Paul. When are the 2.2.0 packages planned to arrive? I can provide these over the weekend if people are waiting for them...

Some files are missing, ipsec setup start complains about missing id an tr...

Yeah, you will have to recompile openwrt (well, busybox actually) to include those, or modify the openswan scripts to not use these tools. You can snag openswan packages from http://www.linuxops.net/ipkg/ which have this problem solved (albeit have some others).

Are there any known problems regarding reading connection entries from /etc/ipsec.conf ?

Sep 28 12:13:38 193.17.17.98  pluto[4462]: Starting Pluto (Openswan Version 2.2.0 X.509-1.5.4 PLUTO_USES_KEYRR)
Sep 28 12:13:38 193.17.17.98  pluto[4462]:   including NAT-Traversal patch (Version 0.6c) [disabled]
Sep 28 12:13:38 193.17.17.98  pluto[4462]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
Sep 28 12:13:38 193.17.17.98  pluto[4462]: Changing to directory '/etc/ipsec.d/cacerts'
Sep 28 12:13:38 193.17.17.98  pluto[4462]:   loaded CA cert file 'cacert.pem' (1302 bytes)
Sep 28 12:13:38 193.17.17.98  pluto[4462]: Changing to directory '/etc/ipsec.d/aacerts'
Sep 28 12:13:38 193.17.17.98  pluto[4462]: Changing to directory '/etc/ipsec.d/ocspcerts'
Sep 28 12:13:38 193.17.17.98  pluto[4462]: Changing to directory '/etc/ipsec.d/crls'
Sep 28 12:13:38 193.17.17.98  pluto[4462]:   loaded crl file 'crl.wlan.pem' (524 bytes)
Sep 28 12:13:43 193.17.17.98  pluto[4462]: listening for IKE messages
Sep 28 12:13:43 193.17.17.98  pluto[4462]: adding interface ipsec0/vlan1 193.17.17.98
Sep 28 12:13:43 193.17.17.98  pluto[4462]: adding interface ipsec1/br0 192.168.1.1
Sep 28 12:13:43 193.17.17.98  pluto[4462]: loading secrets from "/etc/ipsec.secrets"
Sep 28 12:13:43 193.17.17.98  pluto[4462]:   loaded private key file '/etc/ipsec.d/private/wrt54gs-0001-key.pem' (963 bytes)

That looks good, but connection defined in /etc/ipsec.conf is missing. Passphrase in /etc/ipsec.secret matches privat key file. Problem is, somewhere messages like that should appear:

Sep 28 12:19:24 cf-eth-gw pluto[13875]:   loaded host cert file '/etc/ipsec.d/certs/cf-eth-gw-cert-0001.pe
m' (1957 bytes)
Sep 28 12:19:24 cf-eth-gw pluto[13875]:   loaded host cert file '/etc/ipsec.d/certs/labpc02-cert.pem' (195
7 bytes)
Sep 28 12:19:24 cf-eth-gw pluto[13875]: added connection description "labpc02"

Output above is taken from log of a running OpenSwan installation on x86 PC.

ipsec auto --up labpc02 fails with message 021 no connection named "labpc02"
Same config file works on x86 OpenSwan PC. Connection definition of wrt54gs:

version 2.0

config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        # plutodebug="control parsing"
        uniqueids=no
        interfaces="ipsec0=vlan1 ipsec1=br0"
        klipsdebug=none
        plutodebug=none

conn labpc02
        type=tunnel
        keyingtries=0
        authby=rsasig
        auto=start
        # Left security gateway, subnet behind it, next hop toward right.
        left=193.17.17.98
        leftsubnet=192.168.1.0/24
        leftrsasigkey=%cert
        leftid="/C=de/..."
        leftcert=/etc/ipsec.d/certs/wrt54gs-0001-cert.pem
        # Right security gateway, subnet behind it, next hop toward left.
        right=193.17.17.99
        rightsubnet=192.168.254.0/24
        rightrsasigkey=%cert
        rightid="/C=de/...."
        rightcert=/etc/ipsec.d/certs/labpc02-cert.pem

Do you have a working example, which is known to be running on OpenWRT ?

Christian

The config as you posted looks ok to me.

I do have a working config, except it's on a router which is switched off, at about 2000km north from here :-)  I have yet to flash my WRT54GS with OpenWRT to set up the VPN connection again.

At any rate, I created openswan 2.2.0 packages, which you can find at http://www.linuxops.net/ipkg/

Due to the fact that I don't have openwrt handy at this time, I haven't been able to test them. They're built against an older release of openwrt, but I don't really expect any problems arising from that. If so, let me know, and I'll recreate them using a more recent buildroot. Some bugs will still be in these packages as I haven't really looked any deeper into things yet. Ergo, /var/lock, /var/lock/subsys and /var/run still need to exist, some scripts might have problems with being run under ash, and dirname and friends are still being relied on here and there.

On a brighter note, the dependency on `tr` and `id` have been removed. Keep an eye out for new packages as I might be able to put in some work to fix various issues soon.

I updated to your new pkgs, but same result: Connection definitions in /etc/ipsec.conf are not loaded.
Some tests with strongawk on WRT54G ran into same results. Debugging of some ipsec scripts showed different behaviour of mawk and gawk.
Now I created my first two ipkg packages:
GNU awk and strongswan.
GNU AWK is a big file (500 KByte) named gawk, which is running on WRT54GS now. That solved the problem but creates a new problem: mawk is smaller (175k) than GNU awk, so two solutions needs to be considered:

Ignore that and change requirements for OpenSwan from WRT54G to WRT54GS. People who are using WRT54G will hate us, but easiest way for us ;-)

Rewrite all awk scripts in /usr/lib/ipsec so they will run on mawk or - better - on internal busybox awk.

My works yielded into a port of StrongSwan, which support more encryption methonds than OpenSwan. Minus of StronSwan is a quite bigger footprint. I am not sure if it makes sense to maintain StronSwan for OpenWRT. Any other opinions ?

Strongswan is a 1MB+ package, that is ok for WRT54GS, but not for WRT54G.

Well, following output looks much better:

root@OpenWrt:/etc# ipsec auto --statusall
000 interface ipsec1/vlan0 192.168.1.1
000 interface ipsec0/vlan1 193.17.17.98
000 %myid = (none)
000 debug none
000
000 "sample": 192.168.1.0/24===193.17.17.98...193.17.17.97[@cf-eth-gw]===192.168.0.0/24; unrouted; erouteowner: #0
000 "sample":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "sample":   policy: RSASIG+ENCRYPT+TUNNEL+PFS; prio: 24,24; interface: vlan1;
000 "sample":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "sample":   IKE algorithms wanted: 5_000-1-5, 5_000-1-2, 5_000-2-5, 5_000-2-2,
000 "sample":   IKE algorithms found:  5_192-1_128-5, 5_192-1_128-2, 5_192-2_160-5, 5_192-2_160-2,
000 "sample":   ESP algorithms wanted: 3_000-1, 3_000-2,
000 "sample":   ESP algorithms loaded: 3_168-1_128, 3_168-2_160,
000
000

and it is fully operational:

root@OpenWrt:~# ipsec auto --up sample
104 "sample" #1: STATE_MAIN_I1: initiate
003 "sample" #1: ignoring Vendor ID payload [strongSwan 2.2.1]
003 "sample" #1: received Vendor ID payload [Dead Peer Detection]
106 "sample" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "sample" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "sample" #1: STATE_MAIN_I4: ISAKMP SA established
112 "sample" #2: STATE_QUICK_I1: initiate
004 "sample" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xd8e23d87 <0xea2cbb46}

To-Do:
Either modifying OpenSwan scripts to run with (m)awk or install gawk and replace /usr/bin/awk->/rom... to /usr/bin/awk->/usr/bin/gawk.
Some more testing on OpenSwan/StrongSwan on WRT54G(S)

Some questions to community:

Is anybody interested in ipkg packages of:
- gawk
- StrongSwan
?

Following bugs in OpenSwan package are discovered:

Critical:
OpenSwan cannot setup connections without gawk. Prerequisite mawk is not valid. It should be replaced by gawk.

cd /usr/bin
rm awk
ln -s gawk awk

after installation of gawk makes OpenSwan 2.2.0 operational.

Not critical
/usr/libexec/ipsec is a dead softlink. It should be relinked to /etc/init.d/S50ipsec

Interoperabiliy issues
If Quagga is installed, Quagga detects ipsec<x> interfaces. That means dynamic routing may break if OpenSwan uses interfaces, which are required by Quagga. Unfortunally that is true for most cases :-( This problem is not specific to OpenWRT, it is a general problem with kernel 2.4.x. That problem no longer exists with kernel 2.6.x ipsec implementation.

An analysis of Quaggas behaviour enables a workaround. Quagga loads interfaces in alphabetical order, so iproute2 package will help us :-)

ifconfig vlan1 down
ip link set vlan1 name a_wan
ifconfig a_wan up
ip route add default via <your default route> dev a_wan

This must be done before OpenSwan is started

Actually, now you mentioned awk...you're aware that the package you installed mawk with didn't replace the symlink either, right? This might explain your problems with it (and also explain why noone else seems to have them). This is a bug in the mawk package, btw.

On a side note, I indeed have an intention of trying to translate all the mawk dependant stuff so that the internal awk can handle it. I hope it's possible, saves a few bytes.