[ previous ] [ next ] [ threads ]
 
 From:  William Arlofski <waa dash m0n0wall at revpol dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Unable to establish IPSec VPN between (2) WRAPs w v1.2b1
 Date:  Sun, 03 Oct 2004 22:33:18 -0400
I have (3) m0n0walls in place, two on WRAPs and on on a PC/CDROM:

A - Home office on PC m0n0 v1.2b1  (cable modem)
B - Client main site on WRAP 1D1 m0n0 v1.2b1 (Frame Relay T1)
C - Client remote site on WRAP 1D1 m0n0 v1.2b1 (DSL)


I am able to create working VPNs between A <-> B  and A <-> C, but I am 
unable to create a VPN between B <-> C (which is the actual purpose of 
this project)

The only factor I can determine here is that I am unable to create a VPN 
between 2 WRAPs running v1.2b1 of m0n0wall.

I notice in the logs of systems B and C that when The VPN is enabled, it 
never even appears to begin the connecion to the other side, even though 
"Automatically establish this connection" is checked on both ends.

The logs show that it stops after (re)creating the SPD policies. This 
log snip is from system B after saving the IPSec tunnel config.

Oct  3 21:02:24 vpn racoon: INFO: session.c:180:close_session(): racoon 
shutdown
Oct  3 21:02:25 vpn racoon: INFO: main.c:172:main(): @(#)package version 
freebsd-20040617a
Oct  3 21:02:25 vpn racoon: INFO: main.c:174:main(): @(#)internal 
version 20001216 sakane at kame dot net
Oct  3 21:02:25 vpn racoon: INFO: main.c:175:main(): @(#)This product 
linked OpenSSL 0.9.7d 17 Mar 2004 (http://www.openssl.org/)
Oct  3 21:02:26 vpn racoon: INFO: isakmp.c:1368:isakmp_open(): 
127.0.0.1[500] used as isakmp port (fd=7)
Oct  3 21:02:26 vpn racoon: INFO: isakmp.c:1368:isakmp_open(): 
10.1.99.1[500] used as isakmp port (fd=8)
Oct  3 21:02:26 vpn racoon: INFO: isakmp.c:1368:isakmp_open(): 
12.39.80.117[500] used as isakmp port (fd=9)
Oct  3 21:02:26 vpn racoon: ERROR: pfkey.c:2292:pk_recvspddump(): such 
policy already exists. anyway replace it: 10.1.99.0/24[0] 
10.1.99.1/32[0] proto=any dir=in
Oct  3 21:02:26 vpn racoon: ERROR: pfkey.c:2292:pk_recvspddump(): such 
policy already exists. anyway replace it: 192.168.1.0/24[0] 
10.0.0.0/8[0] proto=any dir=in
Oct  3 21:02:26 vpn racoon: ERROR: pfkey.c:2292:pk_recvspddump(): such 
policy already exists. anyway replace it: 10.1.99.1/32[0] 
10.1.99.0/24[0] proto=any dir=out
Oct  3 21:02:26 vpn racoon: ERROR: pfkey.c:2292:pk_recvspddump(): such 
policy already exists. anyway replace it: 10.0.0.0/8[0] 
192.168.1.0/24[0] proto=any dir=out


When a VPN tunnel is established between system A (named vai) and system 
C for example, vai's logs show the following immediately after the 
policy replacement log entries similar to those above.

69.xxx.xxx.84 is system C
67.xxx.xxx.239 is system A (vai)

  vai racoon: INFO: isakmp.c:1694:isakmp_post_acquire(): IPsec-SA 
request for 69.xxx.xxx.84 queued due to no phase1 found.
Oct  3 21:56:04 vai racoon: INFO: isakmp.c:808:isakmp_ph1begin_i(): 
initiate new phase 1 negotiation: 67.xxx.xxx.239[500]<=>69.xxx.xxx.84[500]
Oct  3 21:56:04 vai racoon: INFO: isakmp.c:813:isakmp_ph1begin_i(): 
begin Aggressive mode.
Oct  3 21:56:05 vai racoon: INFO: vendorid.c:128:check_vendorid(): 
received Vendor ID: KAME/racoon
Oct  3 21:56:05 vai racoon: NOTIFY: oakley.c:2084:oakley_skeyid(): 
couldn't find the proper pskey, try to get one by the peer's address.
Oct  3 21:56:05 vai racoon: INFO: isakmp.c:2459:log_ph1established(): 
ISAKMP-SA established 67.xxx.xxx.239[500]-69.xxx.xxx.84[500] 
spi:7f16ce8ba9aeb2b0:819c7c465c1c7194
Oct  3 21:56:05 vai racoon: INFO: isakmp.c:952:isakmp_ph2begin_i(): 
initiate new phase 2 negotiation: 67.xxx.xxx.239[0]<=>69.xxx.xxx.84[0]
Oct  3 21:56:06 vai racoon: INFO: pfkey.c:1197:pk_recvupdate(): IPsec-SA 
established: ESP/Tunnel 69.xxx.xxx.84->67.xxx.xxx.239 
spi=197996758(0xbcd30d6)
Oct  3 21:56:06 vai racoon: INFO: pfkey.c:1420:pk_recvadd(): IPsec-SA 
established: ESP/Tunnel 67.xxx.xxx.239->69.xxx.xxx.84 
spi=93177818(0x58dc7da)

...and the tunnel is established between systems A and B, and all is 
fine. This process also works between systems A and C as stated above.


Any ideas why it appears to be impossible to create a tunnel between the 
2 WRAPs?   Any ideas wht neither system B or C ever see the IPsec-SA 
request from the other to begin the tunnel?  I have proven that system B 
and system C can send packets to each other by pinging each from the 
other and watching the firewall logs.

I have been over the IPSec configs on both WRAPS with a fine toothed 
comb more times that I want to count... but I would be happy to post the 
configs - or probably better - the status.php outputs if that would help.

I am completely stuck here and my next thought is to put version 1.1 on 
both of the WRAPS and give that a try.

Thanks in advance for any input.

- -
Bill Arlofski
waa dash m0n0wall at revpol dot com