It seems to me that there is some glitch in the up/down
scripts in the newest 3.020 version of ASL that incorrectly
states that it could not establish an IPsec link.
Output from /var/log/auth on left subnet (running 2.019):
Jan 30 05:25:41 asl Pluto[14891]: | inserting event EVENT_SA_REPLACE, timeout in 28500 seconds for #9
->>Jan 30 05:25:41 asl Pluto[14891]: "to-bergen_1" #9: STATE_QUICK_R2: IPsec SA established
Jan 30 05:25:41 asl Pluto[14891]: | next event EVENT_RETRANSMIT in 4 seconds for #7
/var/log/daemon on left side:
Jan 29 05:23:17 asl ipsec_setup: KLIPS debug `none'
Jan 29 05:23:17 asl ipsec_setup: KLIPS ipsec0 on eth0 10.0.8.251/255.255.255.0 broadcast 10.0.8.255
Jan 29 05:23:17 asl ipsec_setup: KLIPS ipsec1 on eth1 169.207.147.131/255.255.255.240 broadcast 169.207.147.143
Jan 29 05:23:18 asl ipsec_setup: Pluto debug `all'
Jan 29 05:23:19 asl ipsec_setup: 104 "to-bergen_1" #1: STATE_MAIN_I1: initiate
Jan 29 05:23:19 asl ipsec_setup: ...FreeS/WAN IPSEC started
Jan 29 05:24:54 asl daemon-watcher[474]: Watching superdaemon.pl ALL OK
Output from /var/log/auth on right subnet (running 3.020):
Jan 30 12:25:23 vpn-gw Pluto[29191]: | inserting event EVENT_SA_REPLACE, timeout in 27978 seconds for #2
->>Jan 30 12:25:23 vpn-gw Pluto[29191]: "to-milwaukee_1" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
Jan 30 12:25:23 vpn-gw Pluto[29191]: | next event EVENT_SHUNT_SCAN in 105 seconds
/var/log/daemon on right side: (ASL 3.020)
Jan 30 12:25:08 vpn-gw ipsec_setup: ...FreeS/WAN IPsec started
Jan 30 12:25:11 vpn-gw ipsec__plutorun: 104 "to-milwaukee_1" #1: STATE_MAIN_I1: initiate
Jan 30 12:25:11 vpn-gw ipsec__plutorun: ...could not start conn "to-milwaukee_1"
Jan 30 13:30:58 vpn-gw daemon-watcher[394]: Watching superdaemon.pl ALL OK
Clearly, it states that something is wrong here, so I started
to investigate. I haven't been able to spot that the connection
was running well until now, because we are using a second
VPN solution in which all clients' default gateways are configured
to route through.
Naturally, since time was a major factor here, I downloaded
the stable release and installed that.
After the quick and extremely comfortable setup (big kudos to you
guys!), i looked in /var/log/auth to see if the tunnel was
established and if the output was any different from the 3.020
version - which it wasn't. It came to the same point
in the connection where a Security Association is
established between the two gateways; just as it did in the
devel version (the only change being that it didn't
complain that there was something wrong with the connection
in /var/log/daemon)
As far as I can tell, the communication is up between the two
networks and all is (for the time being) running well.
Anyone else that has experienced this problem in the development
version? It has sure caused some major frustration on my
part.
For an otherwise *excellent* product, this is the onlyproblem
I've experienced so far.
Keep up the good work.
Regards,
// Martin
Guest User!
You are not Sophos Staff.