Thread Info
  • State Not Answered
  • Replies 16 replies
  • Subscribers 0 subscribers
  • Views 13005 views
  • Users 0 members are here
Options
Suggested

[7.395] Site-to-Site VPN not autostarting

Lionking
Still my IPsec VPN siste-to-site is not autostarting after reboot, always have to disable/enable the connection to get it going. I'm running IPsec with RSA-key, remote gateway (ASG 6.314) is initiating the connection.
  • 0
    Could you provide a IPsec log snippet, please?
  • 0 in reply to d12fk
    Hi,

    you can try to reduce the MTU size under Site-to-Site-VPN IPSec Advanced.

    Johannes
  • 0 in reply to Lionking
    Thanks for the log. Findings are two lines stating:

    "S_REF_pnKrJatNZI_0/1": we have no ipsecN interface for either end of this connection

    during startup. I presume you have IPsec bound to some sort of dynamic interface (DSL, Cable, ...)? It looks like the interface is not yet available when pluto starts up. Could you check the corresponding log file (pppoe or whatever) for the time the error shows up in ipsec.log and report what you see there.
  • 0 in reply to d12fk
    Yes, it looks like the interface is ready one second after ipsec starts, bummer.


    2009:02:20-00:12:13 (none) dhcpcd[3390]: broadcasting DHCP_REQUEST for XX.***.***.***
    2009:02:20-00:12:14 (none) syslog-ng[2672]: new configuration initialized
    2009:02:20-00:12:17 (none) snmpd[3520]: cannot open /proc/net/dev ...
    2009:02:20-00:12:17 (none) dhcpcd[3390]: dhcpIPaddrLeaseTime=1200 in DHCP server response.
    2009:02:20-00:12:17 (none) dhcpcd[3390]: dhcpT1value is missing in DHCP server response. Assuming 600 sec
    2009:02:20-00:12:17 (none) dhcpcd[3390]: dhcpT2value is missing in DHCP server response. Assuming 1050 sec
    2009:02:20-00:12:17 (none) dhcpcd[3390]: DHCP_ACK received from  (212.181.166.218)
    2009:02:20-00:12:18 (none) dhcpc-sh: DHCP connection fine. Checking again in 60 seconds
  • 0 in reply to Lionking
    Could you also post the output of ifconfig after a reboot, please. When IPsec is in broken state, that is.
  • 0 in reply to d12fk
    vretstorp:/root # ifconfig
    eth0      Link encap:Ethernet  HWaddr 00:30:18:AE:0F:F7  
              inet addr:15.164.2.1  Bcast:15.164.2.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:5683 errors:0 dropped:0 overruns:0 frame:0
              TX packets:5285 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:1663424 (1.5 Mb)  TX bytes:3974227 (3.7 Mb)
              Interrupt:185 

    eth1      Link encap:Ethernet  HWaddr 00:30:18:AE:0F:F6  
              inet addr:XX.***.***.***  Bcast:XX.***.***.255  Mask:255.255.255.0
              UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:5761 errors:0 dropped:0 overruns:0 frame:0
              TX packets:6590 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:3744152 (3.5 Mb)  TX bytes:1705196 (1.6 Mb)
              Interrupt:193 Base address:0x2000 

    ifb0      Link encap:Ethernet  HWaddr 7E:40:E4:82:54:73  
              UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:2 overruns:0 frame:0
              TX packets:11474 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:32 
              RX bytes:0 (0.0 b)  TX bytes:7483742 (7.1 Mb)

    ipsec0    Link encap:Ethernet  HWaddr 00:30:18:AE:0F:F6  
              UP RUNNING NOARP  MTU:1420  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:10 
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

    lo        Link encap:Local Loopback  
              inet addr:127.0.0.1  Mask:255.0.0.0
              UP LOOPBACK RUNNING  MTU:16436  Metric:1
              RX packets:11864 errors:0 dropped:0 overruns:0 frame:0
              TX packets:11864 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0 
              RX bytes:6201049 (5.9 Mb)  TX bytes:6201049 (5.9 Mb)

    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
              inet addr:10.242.2.1  P-t-P:10.242.2.2  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100 
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
  • 0 in reply to Lionking
    My site-to-site VPN also did not auto-start after up2dating to 7.395.

    ipsec.log: 
    2009:02:20-16:01:54 (none) ipsec_starter[3342]: Starting strongSwan 4.2.3 IPsec [starter]...

    2009:02:20-16:01:54 (none) ipsec_starter[3353]: IP address or index of physical interface changed -> reinit of ipsec interface

    2009:02:20-16:01:54 (none) pluto[3356]: Starting Pluto (strongSwan Version 4.2.3 THREADS LIBLDAP VENDORID CISCO_QUIRKS)

    2009:02:20-16:01:54 (none) pluto[3356]:   including NAT-Traversal patch (Version 0.6c)

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_AES_CBC encryption: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_BLOWFISH_CBC encryption: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_SERPENT_CBC encryption: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_SHA2_256 hash: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_SHA2_384 hash: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_SHA2_512 hash: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_TWOFISH_CBC encryption: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: ike_alg: Activating OAKLEY_TWOFISH_CBC_SSH encryption: Ok

    2009:02:20-16:01:54 (none) pluto[3356]: Testing registered IKE encryption algorithms:

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_DES_CBC self-test not available

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_BLOWFISH_CBC self-test not available

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_3DES_CBC self-test not available

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_AES_CBC self-test not available

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SERPENT_CBC self-test not available

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_TWOFISH_CBC self-test not available

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_TWOFISH_CBC_SSH self-test not available

    2009:02:20-16:01:54 (none) pluto[3356]: Testing registered IKE hash algorithms:

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_MD5 hash self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_MD5 hmac self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA hash self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA hmac self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA2_256 hash self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA2_256 hmac self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA2_384 hash self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA2_384 hmac self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA2_512 hash self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]:   OAKLEY_SHA2_512 hmac self-test passed

    2009:02:20-16:01:54 (none) pluto[3356]: All crypto self-tests passed

    2009:02:20-16:01:54 (none) pluto[3356]: Using KLIPS IPsec interface code

    2009:02:20-16:01:54 (none) pluto[3356]: Changing to directory '/etc/ipsec.d/cacerts'

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded CA cert file 'REF_TTJyRSxYhc.pem' (3009 bytes)

    2009:02:20-16:01:54 (none) pluto[3356]: Changing to directory '/etc/ipsec.d/aacerts'

    2009:02:20-16:01:54 (none) pluto[3356]: Changing to directory '/etc/ipsec.d/ocspcerts'

    2009:02:20-16:01:54 (none) pluto[3356]: Changing to directory '/etc/ipsec.d/crls'

    2009:02:20-16:01:54 (none) pluto[3356]: listening for IKE messages

    2009:02:20-16:01:54 (none) pluto[3356]: no public interfaces found

    2009:02:20-16:01:54 (none) pluto[3356]: loading secrets from "/etc/ipsec.secrets"

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]:   loaded shared key for a.b.c.d 1.2.3.4 

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_0"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_0": we have no ipsecN interface for either end of this connection

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_1"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_1": we have no ipsecN interface for either end of this connection

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_2"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_2": we have no ipsecN interface for either end of this connection

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_3"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_3": we have no ipsecN interface for either end of this connection

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_4"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_4": we have no ipsecN interface for either end of this connection

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_5"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_5": we have no ipsecN interface for either end of this connection

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_6"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_6": we have no ipsecN interface for either end of this connection

    2009:02:20-16:01:54 (none) pluto[3356]: added connection description "S_REF_rlKUFVAhyL_7"

    2009:02:20-16:01:54 (none) pluto[3356]: "S_REF_rlKUFVAhyL_7": we have no ipsecN interface for either end of this connection


    Barry
  • 0 in reply to BarryG
    Okay, I just tested this and have to say 'It works with 7.395 RC2'. I did not use v6 on the initiating site, though. But that should not matter if you say it already worked before v7.400 BETA. Did it?

    For the test I configured IPSec RSA, DSL and DynDNS on the respond-site. I guessed that setup because you did not tell us. The tunnel came up. Then I rebooted the respond-site. The tunnel came up again after the expected timeout (The initiating site needs some time to update the DynDNS Host-Object).

    I've also tested with DSL interface not instantly getting online after reboot. The tunnel came up after the DSL device got the IP, updated the Dyndns and the remote Site re-resolved the Host-Object. All this resolving-stuff may take up to three minutes or even more if respond-site does not update DynDNS instantly, perhaps you were'nt patient enough?

    So, I can' t reproduce it. If you are still sure there is a problem, please exactly describe your setup and what you did (How you updated version etc., if there was a time where it worked etc.).
  • 0 in reply to trollvottel
    You guessed right about my setup on the respond side. Everything worked on 7.306.
    When I reboot the respond side, I almost never get a new IP-address, I have to have it shutdown for about 20 min. for that to happen, so DynDNS is no problem. I've waited up to 10 min. after reboot and the IPsec-tunnel does not come up. I've reinstalled the beta once, ver. 7.380 than up to 7.395.
Unfiltered HTML