[7.395] Site-to-Site VPN not autostarting

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.

Parents

0 d12fk over 15 years ago

Could you provide a IPsec log snippet, please?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Johannes Hiby over 15 years ago in reply to d12fk

Hi,

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

Johannes
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Lionking over 15 years ago 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)
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 BarryG over 15 years ago 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 trollvottel over 15 years ago 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.).
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Lionking over 15 years ago 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.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 trollvottel over 15 years ago in reply to Lionking

You use DSL on the respond-side? Is the problem the DSL interface not getting an IP after reboot or what? If so, the problem lies there and not with IPSec.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Lionking over 15 years ago in reply to trollvottel

No problem getting IP-address after reboot, just problem with IP-sec not starting
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 BarryG over 15 years ago in reply to trollvottel

Mario, my site-to-site was to a v7.306 remote, in non-initiate mode with a static ethernet connection, with my home firewall running the beta in initiate with a cable modem DHCP connection.
All I did was apply the up2date on a working 7.390 system, which iirc was from a 7.380 ISO install. The VPNs had been created in the betas, not imported from a backup.

I did not have any problems with IP connectivity; only with the site-to-site not starting after the up2date/reboot.

Barry
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 trollvottel over 15 years ago in reply to BarryG

I just re-checked with DSL interface being down much longer. The initiating-side increased its timeout for connecting so that it showed an retry-connection attempt only every ~12 minutes in ipsec.log.

Still, after the respond-side came up again, after a few minutes the tunnel was builtup successfully.

Log of initiating-side:

[...]
2009:02:24-08:35:29 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #95: initiating Main Mode to replace #94
2009:02:24-08:48:39 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #95: max number of retransmissions (20) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
2009:02:24-08:48:39 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #95: starting keying attempt 87 of an unlimited number
2009:02:24-08:48:39 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #96: initiating Main Mode to replace #95
2009:02:24-09:01:49 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #96: max number of retransmissions (20) reached STATE_MAIN_I1.  No response (or no acceptable response) to our first IKE message
2009:02:24-09:01:49 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #96: starting keying attempt 88 of an unlimited number
2009:02:24-09:01:49 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #97: initiating Main Mode to replace #96
2009:02:24-09:14:20 mst-pferd pluto[7233]: forgetting secrets
2009:02:24-09:14:20 mst-pferd pluto[7233]: loading secrets from "/etc/ipsec.secrets"
2009:02:24-09:14:20 mst-pferd pluto[7233]: Changing to directory '/etc/ipsec.d/cacerts'
2009:02:24-09:14:20 mst-pferd pluto[7233]:   loaded CA cert file 'REF_CeRlOuUqoa.pem' (3053 bytes)
2009:02:24-09:14:20 mst-pferd pluto[7233]: Changing to directory '/etc/ipsec.d/aacerts'
2009:02:24-09:14:20 mst-pferd pluto[7233]: Changing to directory '/etc/ipsec.d/ocspcerts'
2009:02:24-09:14:20 mst-pferd pluto[7233]: Changing to directory '/etc/ipsec.d/crls'
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0": deleting connection
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #97: deleting state (STATE_MAIN_I1)
2009:02:24-09:14:20 mst-pferd pluto[7233]: added connection description "S_REF_iDVypvbcvH_0"
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: initiating Main Mode
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: ignoring Vendor ID payload [strongSwan 4.2.3]
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: ignoring Vendor ID payload [Cisco-Unity]
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: received Vendor ID payload [XAUTH]
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: received Vendor ID payload [Dead Peer Detection]
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: received Vendor ID payload [RFC 3947]
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: enabling possible NAT-traversal with method 3
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: NAT-Traversal: Result using RFC 3947: no NAT detected
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: we don't have a cert
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: Peer ID is ID_FQDN: '@mst-meiler.qa.astaro.de'
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #98: ISAKMP SA established
2009:02:24-09:14:20 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #99: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+UP {using isakmp#98}
2009:02:24-09:14:21 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #99: Dead Peer Detection (RFC 3706) enabled
2009:02:24-09:14:21 mst-pferd pluto[7233]: "S_REF_iDVypvbcvH_0" #99: sent QI2, IPsec SA established {ESP=>0x12b31b5d

respond-side:

[...]
2009:02:24-09:11:28 mst-meiler ipsec_starter[12974]: Starting strongSwan 4.2.3 IPsec [starter]...
2009:02:24-09:11:28 mst-meiler ipsec_starter[12985]: IP address or index of physical interface changed -> reinit of ipsec interface
2009:02:24-09:11:28 mst-meiler pluto[12988]: Starting Pluto (strongSwan Version 4.2.3 THREADS LIBLDAP VENDORID CISCO_QUIRKS)
2009:02:24-09:11:28 mst-meiler pluto[12988]:   including NAT-Traversal patch (Version 0.6c)
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_AES_CBC encryption: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_BLOWFISH_CBC encryption: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_SERPENT_CBC encryption: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_SHA2_256 hash: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_SHA2_384 hash: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_SHA2_512 hash: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_TWOFISH_CBC encryption: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: ike_alg: Activating OAKLEY_TWOFISH_CBC_SSH encryption: Ok
2009:02:24-09:11:28 mst-meiler pluto[12988]: Testing registered IKE encryption algorithms:
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_DES_CBC self-test not available
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_BLOWFISH_CBC self-test not available
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_3DES_CBC self-test not available
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_AES_CBC self-test not available
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SERPENT_CBC self-test not available
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_TWOFISH_CBC self-test not available
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_TWOFISH_CBC_SSH self-test not available
2009:02:24-09:11:28 mst-meiler pluto[12988]: Testing registered IKE hash algorithms:
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_MD5 hash self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_MD5 hmac self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA hash self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA hmac self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA2_256 hash self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA2_256 hmac self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA2_384 hash self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA2_384 hmac self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA2_512 hash self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]:   OAKLEY_SHA2_512 hmac self-test passed
2009:02:24-09:11:28 mst-meiler pluto[12988]: All crypto self-tests passed
2009:02:24-09:11:28 mst-meiler pluto[12988]: Using KLIPS IPsec interface code
2009:02:24-09:11:28 mst-meiler pluto[12988]: Changing to directory '/etc/ipsec.d/cacerts'
2009:02:24-09:11:28 mst-meiler pluto[12988]:   loaded CA cert file 'REF_uauraoGisx.pem' (3053 bytes)
2009:02:24-09:11:28 mst-meiler pluto[12988]: Changing to directory '/etc/ipsec.d/aacerts'
2009:02:24-09:11:28 mst-meiler pluto[12988]: Changing to directory '/etc/ipsec.d/ocspcerts'
2009:02:24-09:11:28 mst-meiler pluto[12988]: Changing to directory '/etc/ipsec.d/crls'
2009:02:24-09:11:28 mst-meiler pluto[12988]: listening for IKE messages
2009:02:24-09:11:28 mst-meiler pluto[12988]: adding interface ipsec0/ppp0 10.0.6.143:500
2009:02:24-09:11:28 mst-meiler pluto[12988]: adding interface ipsec0/ppp0 10.0.6.143:4500
2009:02:24-09:11:28 mst-meiler pluto[12988]: loading secrets from "/etc/ipsec.secrets"
2009:02:24-09:11:28 mst-meiler pluto[12988]: added connection description "S_REF_QoOJMaSwnx_0"
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: ignoring Vendor ID payload [strongSwan 4.2.3]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: ignoring Vendor ID payload [Cisco-Unity]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: received Vendor ID payload [XAUTH]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: received Vendor ID payload [Dead Peer Detection]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: received Vendor ID payload [RFC 3947]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2009:02:24-09:14:20 mst-meiler pluto[12988]: packet from 10.8.1.4:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2009:02:24-09:14:20 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #1: responding to Main Mode from unknown peer 10.8.1.4
2009:02:24-09:14:20 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #1: NAT-Traversal: Result using RFC 3947: no NAT detected
2009:02:24-09:14:20 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #1: Peer ID is ID_FQDN: '@mst-pferd.qa.astaro.de'
2009:02:24-09:14:20 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #1: we don't have a cert
2009:02:24-09:14:20 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #1: sent MR3, ISAKMP SA established
2009:02:24-09:14:20 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #2: responding to Quick Mode 
2009:02:24-09:14:21 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #2: Dead Peer Detection (RFC 3706) enabled
2009:02:24-09:14:21 mst-meiler pluto[12988]: "S_REF_QoOJMaSwnx_0"[1] 10.8.1.4 #2: IPsec SA established {ESP=>0xf17f393b

0 BarryG over 15 years ago in reply to trollvottel

After updating from 7.395 to 7.400, my site-to-site IPSec VPN was down again.

Barry
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Lionking over 15 years ago in reply to BarryG

Same here, not funny
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Lionking over 15 years ago in reply to BarryG

Same here, not funny
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data