Find the answer to your Linux question:
Results 1 to 7 of 7
Linux Openswan IPSec tunnel problems; This issue involves a linux workstation running Cent os 4.4 (2.6.9-42 0.10.EL kernel) and a Fortigate 1000A vpn/firewall. I am attempting to create a full ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Aug 2008
    Posts
    10

    Openswan Ipsec vpn tunnel issues


    Linux Openswan IPSec tunnel problems;

    This issue involves a linux workstation running Cent os 4.4 (2.6.9-42 0.10.EL kernel) and a Fortigate 1000A vpn/firewall.
    I am attempting to create a full time tunnel between the Linux workstation and Fortigate unit, once the connection has been
    Successfully negotiated the Linux box will have access to our internal network resources behind the Fortigate Vpn/firewall.

    I am using a pre-shared-key as well as Xauth for this connection.
    When I bring up the tunnel the terminal requests a user name and password for the Xauth, after I enter the required information
    The tunnel is started and everything then works fine until it is time to rekey...... It looks to me as though the negotiation is partially successful.
    I believe the psk is shared again and that the Xauth that is the problem.

    I can confirm this theory, if I disable the Xauth and simply use a "psk" the connection rekeys and stays open, as desired.
    I have read that Linux Xauth connections can/cannot be rekeyed, so I am some what confused.

    Currently the only solution I see is to run a cron script every 5-6 hours that brings down the tunnel then
    runs a IPSec whack command to reinitiate the tunnel, but this seems a bit crazy.

    here is a copy of /etc/ipsec.conf

    # basic configuration
    config setup
    # plutodebug / klipsdebug = "all", "none" or a combation from below:
    # "raw crypt parsing emitting control klips pfkey natt x509 private"
    # eg:
    # plutodebug="control parsing"
    #
    # Only enable *debug=all if you are a developer
    #
    # NAT-TRAVERSAL support, see README.NAT-Traversal
    nat_traversal=yes
    # exclude networks used on server side by adding %v4:!a.b.c.0/24
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12
    # OE is now off by default. Uncomment and change to on, to enable.
    OE=off
    # which IPsec stack to use. netkey,klips,mast,auto or none
    protostack=netkey

    # My conenction
    conn test
    leftxauthclient=yes
    rightxauthserver=yes
    left=%defaultroute
    leftsourceip=xxx.xxx.xxx.xxx
    right=xxx.xxx.xxx.xxx
    rightsubnet=xxx.xxx.xxx.xxx/xx
    keyexchange=ike
    auth=esp
    authby=secret
    esp=3des
    compress=no
    pfs=yes
    auto=add
    ikelifetime=24h
    keylife=8h
    rekey=yes

    I will also include a copy of the secure log (showing from the start to the end of the tunnels life) on the linux client

    ###### CONNECTION STARTED HERE #########
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: initiating Main Mode
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: received Vendor ID payload [RFC 3947] method set to=109
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: received Vendor ID payload [Dead Peer Detection]
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: enabling possible NAT-traversal with method 4
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: STATE_MAIN_I2: sent MI2, expecting MR2
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: STATE_MAIN_I3: sent MI3, expecting MR3
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: Main mode peer ID is ID_IPV4_ADDR: '70.67.129.119'
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
    Aug 11 15:38:33 claimtools pluto[6219]: "test" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
    group=modp1536}
    Aug 11 15:38:39 claimtools pluto[6219]: "test" #1: XAUTH: Answering XAUTH challenge with user='claimtools-0212'
    Aug 11 15:38:39 claimtools pluto[6219]: "test" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1
    Aug 11 15:38:39 claimtools pluto[6219]: "test" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #1: XAUTH: Successfully Authenticated
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to
    dev@openswan.org
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to
    dev@openswan.org
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to
    dev@openswan.org
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to
    dev@openswan.org
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW {using isakmp#1 msgid:197dcd2f proposal=3DES(3)_192-MD5(1)_128, 3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1536}
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME msgid=197dcd2f
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
    Aug 11 15:38:40 claimtools pluto[6219]: "test" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x89f86b92 <0x51e06c8a xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=none DPD=none}
    Aug 11 15:39:03 claimtools pluto[6219]: packet from 70.67.129.119:4500: ignoring Delete SA payload: not encrypted
    Aug 11 15:39:03 claimtools pluto[6219]: packet from 70.67.129.119:4500: received and ignored informational message
    Aug 11 17:37:15 claimtools pluto[6219]: ERROR: recvfrom on eth0 failed; Pluto cannot decode source sockaddr in rejection: unknown source. Errno 11: Resource
    temporarily unavailable
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #1: the peer proposed: 192.168.22.29/32:0/0 -> 192.168.80.0/24:0/0
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to
    dev@openswan.org
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to
    dev@openswan.org
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to
    dev@openswan.org
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #1: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to
    dev@openswan.org
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #3: responding to Quick Mode proposal {msgid:ec4e478a}
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #3: us: 192.168.22.29/32===192.168.22.204[+XC+S=C]
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #3: them: 70.67.129.119<70.67.129.119>[+XS+S=C]===192.168.80.0/24
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #3: keeping refhim=4294901761 during rekey
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #3: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #3: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
    Aug 11 17:38:30 claimtools pluto[6219]: "test" #3: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2

    Aug 11 17:38:40 claimtools pluto[6219]: "test" #1: received Delete SA(0x89f86b92) payload: deleting IPSEC State #2
    Aug 11 17:38:40 claimtools pluto[6219]: "test" #1: received and ignored informational message
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: initiating Main Mode
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: received Vendor ID payload [RFC 3947] method set to=109
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: received Vendor ID payload [Dead Peer Detection]
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: enabling possible NAT-traversal with method 4
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: STATE_MAIN_I2: sent MI2, expecting MR2
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: STATE_MAIN_I3: sent MI3, expecting MR3
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: Main mode peer ID is ID_IPV4_ADDR: '70.67.129.119'
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
    group=modp1536}
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #1: received Delete SA payload: replace IPSEC State #3 in 10 seconds
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #1: received and ignored informational message
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #1: received Delete SA payload: deleting ISAKMP State #1
    Aug 11 19:34:00 claimtools pluto[6219]: packet from 70.67.129.119:4500: received and ignored informational message
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: XAUTH username requested, but no file descriptor available for prompt
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: sending encrypted notification CERTIFICATE_UNAVAILABLE to 70.67.129.119:4500
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #5: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #3 {using isakmp#4 msgid:14d475fd proposal=3DES(3)_192-MD5(1)_128, 3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1536}
    Aug 11 19:34:20 claimtools pluto[6219]: "test" #3: IPsec SA expired (LATEST!)
    Aug 11 19:34:20 claimtools pluto[6219]: "test" #3: request to replace with shunt a prospective erouted policy with netkey kernel --- experimental
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode
    message: perhaps peer likes no proposal
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: starting keying attempt 2 of at most 3
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #6: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #5 {using isakmp#4 msgid:ac8007e7 proposal=3DES(3)_192-MD5(1)_128, 3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1536}
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode
    message: perhaps peer likes no proposal
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: starting keying attempt 3 of at most 3

    Aug 11 17:38:40 claimtools pluto[6219]: "test" #1: received Delete SA(0x89f86b92) payload: deleting IPSEC State #2
    Aug 11 17:38:40 claimtools pluto[6219]: "test" #1: received and ignored informational message
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: initiating Main Mode
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: received Vendor ID payload [RFC 3947] method set to=109
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: received Vendor ID payload [Dead Peer Detection]
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: enabling possible NAT-traversal with method 4
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: STATE_MAIN_I2: sent MI2, expecting MR2
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: STATE_MAIN_I3: sent MI3, expecting MR3
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: Main mode peer ID is ID_IPV4_ADDR: '70.67.129.119'
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
    group=modp1536}
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #1: received Delete SA payload: replace IPSEC State #3 in 10 seconds
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #1: received and ignored informational message
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #1: received Delete SA payload: deleting ISAKMP State #1
    Aug 11 19:34:00 claimtools pluto[6219]: packet from 70.67.129.119:4500: received and ignored informational message
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: XAUTH username requested, but no file descriptor available for prompt
    Aug 11 19:34:00 claimtools pluto[6219]: "test" #4: sending encrypted notification CERTIFICATE_UNAVAILABLE to 70.67.129.119:4500
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #3: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:34:10 claimtools pluto[6219]: "test" #5: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #3 {using isakmp#4 msgid:14d475fd proposal=3DES(3)_192-MD5(1)_128, 3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1536}
    Aug 11 19:34:20 claimtools pluto[6219]: "test" #3: IPsec SA expired (LATEST!)
    Aug 11 19:34:20 claimtools pluto[6219]: "test" #3: request to replace with shunt a prospective erouted policy with netkey kernel --- experimental
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode
    message: perhaps peer likes no proposal
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: starting keying attempt 2 of at most 3
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #5: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:35:20 claimtools pluto[6219]: "test" #6: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #5 {using isakmp#4 msgid:ac8007e7 proposal=3DES(3)_192-MD5(1)_128, 3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1536}
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode
    message: perhaps peer likes no proposal
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: starting keying attempt 3 of at most 3

    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_er in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pi in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #6: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_pr in duplicate_state, please report to
    dev@openswan.org
    Aug 11 19:36:30 claimtools pluto[6219]: "test" #7: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #6 {using isakmp#4 msgid:386b5bbe proposal=3DES(3)_192-MD5(1)_128, 3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1536}
    Aug 11 19:37:40 claimtools pluto[6219]: "test" #7: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode
    message: perhaps peer likes no proposal
    Aug 11 20:36:26 claimtools pluto[6219]: "test" #4: DPD Info: received old or duplicate R_U_THERE
    Aug 11 20:36:31 claimtools pluto[6219]: "test" #4: DPD Info: received old or duplicate R_U_THERE
    Aug 11 20:36:36 claimtools pluto[6219]: "test" #4: received Delete SA payload: deleting ISAKMP State #4
    Aug 11 20:36:36 claimtools pluto[6219]: packet from 70.67.129.119:4500: received and ignored informational message

  2. #2
    Just Joined!
    Join Date
    Aug 2008
    Posts
    7
    same problem using debian testing (currently lenny) and kernel 2.6.24....
    the line XAUTH username requested, but no file descriptor available for prompt
    clearly indicates that we should find a way to indicate the xauth username and pasword without prompting.
    btw, i m launching the VPN with a line like
    ipsec whack --name forti --xauthname jimi --xauthpass hendrix --initiate

    so maybe there s a way to fix those parameters directly in the conf file...

    also , xauth support was added to kvpnc in latest svn ,maybe you ll want to give it a try

  3. #3
    Just Joined!
    Join Date
    Aug 2008
    Posts
    10
    Well I talked to an engineer at Fortinet and he had found an article regarding a similar problem. Apparantly the ipsec.conf file should contain these two entries
    1) rekey=no
    2) rekeyfuzz=0%

    Now comes the interesting part when I make the change for rekeyfuzz it gives me a parse error stating that 0% is an invalid paramater, which clearly is not true...... Hopeless lol

  4. #4
    Just Joined!
    Join Date
    Aug 2008
    Posts
    7

    not convinced....

    i dont think those options will do any good, as rekey=no means there wont be renegociation when the key expires , which is exactly waht you want to prevent.
    also rekeyfuzz is meaningless if used without rekeymargin , check man ipsec.conf
    anyway i opened a bug at openswan (0000974) as i think the problem is that when renegociating , openswan cant use the username and password for xauth and cant prompt either for them so exit ( check xauth.c and function xauth_client_resp ). im trying to write an easy patch with a default username/password ,and if it works , i ll try to get this part to rely on environment variables....
    Also i m trying to use a detached screen with a permanent ping on it to see if it works as a workaround

  5. #5
    Just Joined!
    Join Date
    Aug 2008
    Posts
    7
    i ve written two patches on this issue , i m testing basic one right now and it seems to work, you might want to check ticket 0000974 here
    0000974: non interactive xauth_username xauth_password - Openswan bugss
    btw,using the basic patch will imply editing it first to match your default username/password

  6. #6
    Just Joined!
    Join Date
    Aug 2008
    Posts
    10

    patches

    Hey karmatronic, good call on the patches. I have a couple quick questions for you...
    How exactly do these patches work? are they include in an existing file? where should they be located? and how do they run?

  7. #7
    Just Joined!
    Join Date
    Aug 2008
    Posts
    7
    hi jamesj,i finally made a working patch! men i m glad
    to sum up , what you need to do is:
    -grab sources of openswan,and patch the file programs/pluto/xauth.c with the diff named patch_xauth.diff that i ve uploaded on my openswan bug ticket.
    you can use the following command within your openswan source directory
    cd programs/pluto ;
    patch < PATH_TO_patch_xauth.diff

    then run the normal compilation,installation procedure(it also requires instaling some libs,check the README)
    make programs: make install

    and finally use openswan as following:
    -you define environment variables XAUTH_USERNAME and XAUTH_PASSWORD somewhere (e.g /etc/profile) ,that is
    export XAUTH_USERNAME="your user"
    export XAUTH_PASSWORD="your password"

    and then launch ipsec daemon and connections as usual
    you ll be able to confirm it s working when renegocation occurs ,and checking /var/log/auth.log for messages like
    XAUTH username requested, but no file descriptor available for prompt,so using environment
    i have good hope they will merge the code soon

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •