> Thanks for your reply. I already tookout the 'ip_masq_ipseq' > from loading, but still, the exact problem remains. > BTW, the eth1 interface from VPN1 BOX actually goes to > the VPN1 BOX client. Hence, it's actually an internal device. > My diagram is indeed a bit confusing. > I do have some more queries regarding keys and my pluto authlog > though. > Having the authlog below, from my new 'ipsec barf' result, notice > that there are errors generated by Pluto. I've already gotten > openssl.lrp from JNilo's site in order to resolv this. I'm thinking > that Pluto's failure to read the needed certificates brings about > problems in my keying/ipsec.secrets resolution. > Anyways, if I'm not on the right track please let me know.
A couple questions: 1) Why are you loading the ipsec x.509 version of FreeS/WAN when you're not trying to use certificates? You can use conventional RSA signature keys with the x.509 patched version, but in the "walk before you run" catagory, you should probably be using the "plain" version of FreeS/WAN (ie just ipsec.lrp) to get started. The x.509 patches change how pluto responds to connection attempts, and essentially add another layer of potential confusion to your debugging attempts. 2) I've snipped all but the critical errors from your auth.log file below. You really need to look at the logs on *BOTH* ends to figure out what's going wrong. > Jul 30 06:42:11 SR3K-VPN1 Pluto[1737]: "VPN1-VPN2" #1: initiating Main > Mode > Jul 30 06:42:21 SR3K-VPN1 Pluto[1737]: some IKE message we sent has been > rejected with ECONNREFUSED (kernel supplied no details) > Jul 30 06:42:22 SR3K-VPN1 Pluto[1737]: packet from 192.168.2.200:61013: > initial Main Mode message received on 192.168.2.1:500 but no connection > has been authorized The logs indicate two different problems...the first is the IKE message this system sent was rejected by the remote system. This is VERY BAD. There should be a log entry on the remote system indicating *WHY* the packet was refused, which should help track down your configuration error(s). The second problem is the reception of a main-mode message from the remote system that doesn't match a local connection description. This is likely a side-effect of the previous problem. I strongly suggest working with just the plain ipsec.lrp while trying to test your RSA authenticated connection. Once you get that working, you can step up to x.509 certs if necessary. Also, if you post logs again, please do so from *BOTH* machines. For what it's worth, FreeS/WAN is kind of like bind (named)...it seems really complex at first, but it's really pretty simple once you understand how everything works...you should have tunnels up soon! Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
