[Openswan Users] How to see the outgoing decrypted packets with
kernel 2.6 ?
jacquesvalot at hotmail.com
Thu Jun 30 09:28:38 CEST 2005
>From: Paul Wouters <paul at xelerance.com>
>To: Jacques Valot <jacquesvalot at hotmail.com>
>CC: users at openswan.org
>Subject: Re: [Openswan Users] How to see the outgoing decrypted packets
>with kernel 2.6 ?
>Date: Wed, 29 Jun 2005 21:39:19 +0200 (CEST)
>On Wed, 29 Jun 2005, Jacques Valot wrote:
>>>Are the NETKEY modules unloaded properly when using KLIPS?
>>>Did you disable NAT/MASQ? Check ip_forwarding? disable rp_filter?
>>>Any other kernel messages in the log?
>>OK. I have unloaded the modules below before to load ipsec.ko (klips)
>>module and to rerun ipsec service :
>>ah4, esp4, ipcomp, sha1, des, aes-i586, ipsec
>>After this :
>>- On eth0 interface, I see both ESP packets (incoming and outgoing)
>>- On ipsec0 interface, I see outgoing decrypted packets AND incoming
>>decrypted packets too.
>>- The ping now works fine
>What version of openswan is this? Are you using the supplied scripts or is
>on an embedded device with your own scripts? The startup scripts should
>to start openswan when it detects both IPsec stacks are loaded.
I use the openswan 2.3.1 from source file delivered by openswan.org site.
I have installed the product like is indicated in the INSTALL file without
make programs install
Buildings KLIPS kernel module:
make KERNELSRC=/lib/modules/`uname -r`/build module minstall
I have 2 questions :
1. After a reboot of the system. the NETKEY modules are loaded and it's
necessary to unload manually these modules (aes-i586, des, sha1 ipcomp esp4
ah4) after stopped ipec and to load KLIPS module before rerun ipsec.
How to use klips module automaticaly after a reboot and not NETKEY modules ?
2. For 2.3.0 version, I think KLIPS for 2.6 was experimental.
Is-it a problem to use it in place to NETKEY in 2.3.1 version ?
Thank you, Jacques
>>For information :
>># cat /proc/sys/net/ipv4/ip_forward
>>Linux Openswan 2.3.1 (klips)
>That is odd. 2.3.1 should have this check.....
>>Checking for IPsec support in kernel [OK]
>>Checking for RSA private key (/etc/ipsec.secrets) [OK]
>>Checking that pluto is running [OK]
>>Two or more interfaces found, checking IP forwarding [FAILED]
>It might still work if you are using the iptables FORWARD table to
>more finely tune the forwarding, as compared to the on/of switch for the
>ip_forward value in /proc.
>>Opportunistic Encryption DNS checks:
>> Looking for TXT in forward dns zone: neptune [MISSING]
>> Does the machine have at least one non-private address? [FAILED]
>You can ignore these.
>>I am not an ipsec specialist !
>>Do you thing this situation is correct ?
>Yes it is.
> "I am not even supposed to be here today!" -- Clerk
Testez le nouveau MSN Messenger ! http://search.msn.fr/
More information about the Users