Hello,
I'm trying to get Openswan running in a CentOS 4.3 environment. I want to modify as little as possible so that the machine can be kept up to date easily. I'd rather not compile a special kernel, but if that's the only solution, no problem (I don't need NAT traversal).
It's running kernel 2.6.9-34.0.2.EL. Installed the kerneldevel RPM (and kernel src rpm as well). I compiled openswan with: make KERNELSRC=/lib/modules/`uname -r`/build/ module minstall (and same for progs)
Module seems to load fine, lsmod shows as loaded. I do get quite a bit of output on the console that I don't know is normal: ---- Aug 15 12:44:15 INAKFW001 kernel: klips_debug:ipsec_eroute_get_info: buffer=0pc9cce000, *start=0p00000000, offset=61, length=1024 Aug 15 12:44:15 INAKFW001 kernel: klips_debug:rj_walktree: for: rn=0pcce7a5a8 rj_b=-3 rj_flags=6 leaf key = 00000000->00000000 Aug 15 12:44:15 INAKFW001 kernel: klips_debug:rj_walktree: processing leaves, rn=0pcfc9c280 rj_b=-1 rj_flags=4 leaf key = 0a010000->0a020000 Aug 15 12:44:15 INAKFW001 kernel: klips_debug:rj_walktree: while: base=0p00000000 rn=0pcce7a5a8 rj_b=-3 rj_flags=6 leaf key = 00000000->00000000 Aug 15 12:44:15 INAKFW001 kernel: klips_debug:rj_walktree: for: rn=0pcfc9c280 rj_b=-1 rj_flags=4 leaf key = 0a010000->0a020000 Aug 15 12:44:15 INAKFW001 kernel: klips_debug:rj_walktree: processing leaves, rn=0pcce7a5d8 rj_b=-3 rj_flags=6 leaf key = ffffffff->ffffffff Aug 15 12:44:15 INAKFW001 kernel: klips_debug:rj_walktree: while: base=0p00000000 rn=0pcfc9c280 rj_b=-1 rj_flags=4 leaf key = 0a010000->0a020000 Aug 15 12:44:15 INAKFW001 kernel: klips_debug:ipsec_rj_walker_procprint: rn=0pcfc9c280, w0=0pcc83df20 ----
The problem is when I restart the machine, or just restart the service. It panic's :-) Not a good thing for a box that will be hidden in a closet in India :)
I video of the crash can be found at: http://www.brijn.nu/openswan_crash.avi (151Kb)
This machine is running in VMware at the moment. I have the same problem in a "real" machine (identical setup)
Can I build the module as I did, should that work OK? Any other suggestion on what might be wrong?
Thank you very much for your time!
Bas
Bas Rijniersce wrote:
Hello,
I'm trying to get Openswan running in a CentOS 4.3 environment. I want to modify as little as possible so that the machine can be kept up to date easily. I'd rather not compile a special kernel, but if that's the only solution, no problem (I don't need NAT traversal).
Hm, not really answer to your question... But what about native IPSec that is already built into the kernel? It's not perfect (there are some problems with Netfilter and IPSec interacting), but it works for many folks out there. It's easy to setup by hand, or you could use system-config-network too.
It could also be that OpenSwan and native IPSec are clashing...
Hi,
I'm trying to get Openswan running in a CentOS 4.3
environment. I want
to modify as little as possible so that the machine can be
kept up to
date easily. I'd rather not compile a special kernel, but if that's the only solution, no problem (I don't need NAT traversal).
Hm, not really answer to your question... But what about native IPSec that is already built into the kernel? It's not perfect (there are some problems with Netfilter and IPSec interacting), but it works for many folks out there. It's easy to setup by hand, or you could use system-config-network too.
Not having an ipsec interface caused me quite a bit of trouble before. So I really want KLIPS.
It could also be that OpenSwan and native IPSec are clashing...
There is no modules loaded, but who knows. I'm now compiling a custom kernel.. It seems I'll have to live with that.
Bas
Bas Rijniersce wrote:
Not having an ipsec interface caused me quite a bit of trouble before. So I really want KLIPS.
Well, yes, the routing can get a bit non-intuitive and a bit harder to figure out when using native IPSec...
If the other side supports GRE, you can configure the tunnel using GRE, than place it into IPSec. Not ideal solution, but that way you'll get virtual interfaces and conventional routing if you really want/need that tunnel has its own virtual interface. You'd create GRE tunnel between A and B (external addresses of your VPN endpoints), create IPSec policy that traffic between A and B has to be encrypted (the "place GRE tunnel into IPSec" part), than simply route traffic into GRE interfaces. I've used it, it works.
If you go with GRE+IPSec, and you also have firewall on VPN endpoint, you'd want to use IPSec in tunnel mode. Otherwise transport mode will suffice.
-
Aleksandar Milivojevic -
Bas Rijniersce