Log Samples from Racoon VPN

*submited by Charles (kef_list <kef_list@ibacom.es>) to the Ossec List.

Good login:

2006-08-10 19:22:40: INFO: respond new phase 1 negotiation:
111.111.111.194[500]<=>83.36.51.44[500]
2006-08-10 19:22:40: INFO: begin Aggressive mode. 2006-08-10 19:22:40: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-
ike-02
2006-08-10 19:22:41: INFO: ISAKMP-SA established 111.111.111.194
[500]-83.36.51.44[500] spi:3ac2d5023f433d3e:e2d682b6f4fc4830
2006-08-10 19:22:42: INFO: respond new phase 2 negotiation:
111.111.111.194[0]<=>83.36.51.44[0]
2006-08-10 19:22:42: INFO: no policy found, try to generate the
policy : 10.0.1.5/32[0] 10.15.13.224/27[0] proto=any dir=in
2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel
83.36.51.44->111.111.111.194 spi=188599340(0xb3dcc2c)
2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel
111.111.111.194->83.36.51.44 spi=19221256(0x1254b08)
2006-08-10 19:22:42: ERROR: such policy does not already exist:
10.0.1.5/32[0] 10.15.13.224/27[0] proto=any dir=in
2006-08-10 19:22:42: ERROR: such policy does not already exist:
10.0.1.5/32[0] 10.15.13.224/27[0] proto=any dir=fwd
2006-08-10 19:22:42: ERROR: such policy does not already exist:

10.15.13.224/27[0] 10.0.1.5/32[0] proto=any dir=out

This line indicates that the initial phase 1 auth (pskeys or certificates) have been exchanged correctly:

2006-08-10 19:22:41: INFO: ISAKMP-SA established 111.111.111.194 [500]-83.36.51.44[500] spi:3ac2d5023f433d3e:e2d682b6f4fc4830

The other two lines to notice, and the ones that definetly say we have a new VPN established are:

2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel 83.36.51.44->111.111.111.194 spi=188599340(0xb3dcc2c)
2006-08-10 19:22:42: INFO: IPsec-SA established: ESP/Tunnel 111.111.111.194->83.36.51.44 spi=19221256(0x1254b08)

(there are two, one for incomming traffic, another for outgoing traffic).

Strangely enough the last 3 errror lines are NOT errors. They are caused because I am using a “roadwarrior” configuration where connections are allowed from variable IP addresses as opposed to the tipical VPN between two static IPs. They simply indicate that racoon as automatically created security policies for those IPs (and both sides are behind NAT).

Another sample of GOOD login (in this case between two static IPs)

2006-02-19 11:09:25: INFO: respond new phase 1 negotiation: 80.34.246.154[500]<=>217.127.190.50[500]
2006-02-19 11:09:25: INFO: begin Identity Protection mode.
2006-02-19 11:09:26: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
2006-02-19 11:09:26: INFO: ISAKMP-SA established 80.34.246.154 [500]-217.127.190.50[500] spi:bc013ca51d1a8745:9b95e47f6705088b
2006-02-19 11:09:26: INFO: respond new phase 2 negotiation: 80.34.246.154[0]<=>217.127.190.50[0]
2006-02-19 11:09:27: INFO: IPsec-SA established: ESP/Tunnel 217.127.190.50->80.34.246.154 spi=87487840(0x536f560)
2006-02-19 11:09:27: INFO: IPsec-SA established: ESP/Tunnel 80.34.246.154->217.127.190.50 spi=1290938215(0x4cf22767)

As you can see the last two lines are identical as the first case.

WARNING: in both samples they represent a “tunnel” configuration. I do not know what they would look like in “transport” mode....

Now here are some samples of FAILLED logins from hackers trying to get in:

The interesting line is:

Also, there is no INFO: ISAKMP-SA established... line because phase 1 has failed.

Here is another case of invalid login, this time the errors are caused because the hacker has used different settings for the many options that need to be set the same way on both sides to establish a VPN