[leaf-user] subnet-to-subnet simulation problem
Hello everyone, This is actually a freeswan VPN query, so I'm sorry if I had to post this query here also. But I do know that most of you are experts in the VPN field, hence, here goes... I've been trying to do a subnet-to-subnet VPN using my LEAF based routers without success. My setup involves another LEAF machine acting as a virtual internet between the two VPN boxes. Here's a diagram of my setup: VPN1-CLI |eth0: 192.168.4.1 |gw:192.168.4.200 | | |eth1: 192.168.4.200 |gw:192.168.2.1 VPN1 BOX |eth0: 192.168.2.1 |gw: 192.168.2.200 | | |eth1: 192.168.2.200 |gw: 192.168.1.200 ROUTEReth0: 192.168.1.200 |eth2: 192.168.3.200 |gw:192.168.1.200 | | |eth0: 192.168.3.1 |gw:192.168.3.200 VPN2 BOX |eth1: 192.168.5.200 |gw:192.168.3.1 | | |eth0: 192.168.5.1 |gw:192.168.5.200 VPN2-CLI My VPN and ROUTER machines are LEAF/LRP 2.2.19 based, while the VPN-CLI client machines are Win98 PCs. My problem is that, I cannot 'ping' 192.168.4.1 from 192.168.5.1 and vise versa. Upon running 'ipsec look' on either side, I get a 'trap' status instead of a tunnel. SR3K-VPN1 Tue Jul 30 04:02:27 UTC 2002 192.168.4.0/24 -> 192.168.5.0/24 => %trap (0) ipsec0->eth0 mtu=16260(1500)->1500 Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.2.200 0.0.0.0 UG0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 192.168.5.0 192.168.2.200 255.255.255.0 UG0 0 0 ipsec0 I believe there's nothing wrong with my network setup and ipchaining / routing rules as I am able to 'ping' VPN1 BOX from VPN2-CLI, and 'ping' VPN2 BOX from VPN1-CLI. I can also 'ping' VPN1 from VPN2 BOX, and vise versa. Below are some of the listings in my 'ipsec barf' result. I'm currently employing a very lame ipchain rule set just to see this work. Both of my VPN machines are currently using the same set of rules with respect to their network settings. I also tried allowing ipsec protocols to pass thru ROUTER's internal networks thinking it may be needed not! What else am I missing here? TIA - Vic = SR3K-VPN1 Tue Jul 30 03:43:58 UTC 2002 + _ + + ipsec --version Linux FreeS/WAN 1.91 See `ipsec --copyright' for copyright information. + _ + + cat /proc/net/ipsec_eroute 0 192.168.4.0/24 -> 192.168.5.0/24 => %trap + _ + + cat /proc/net/ipsec_spi + _ + + cat /proc/net/ipsec_spigrp + _ + + netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.5.0 192.168.2.200 255.255.255.0 UG0 0 0 ipsec0 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 0.0.0.0 192.168.2.200 0.0.0.0 UG0 0 0 eth0 + _ + + cat /proc/net/ipsec_tncfg ipsec0 -> eth0 mtu=16260(1500) -> 1500 ipsec1 -> NULL mtu=0(0) -> 0 ipsec2 -> NULL mtu=0(0) -> 0 ipsec3 -> NULL mtu=0(0) -> 0 + _ + + cat /proc/net/pf_key sock pid socket next prev e n p sndbfFlags Type St c7278680 1574 c54643b000 0 0 2 32767 3 1 + _ + + cd /proc/net + egrep ^ pf_key_registered pf_key_supported pf_key_registered:satype socket pid sk pf_key_registered: 2 c54643b0 1574 c7278680 pf_key_registered: 3 c54643b0 1574 c7278680 pf_key_registered: 9 c54643b0 1574 c7278680 pf_key_registered:10 c54643b0 1574 c7278680 pf_key_supported:satype exttype alg_id ivlen minbits maxbits pf_key_supported: 2 14 3 0 160 160 pf_key_supported: 2 14 2 0 128 128 pf_key_supported: 3 15 3 128 168 168 pf_key_supported: 3 14 3 0 160 160 pf_key_supported: 3 14 2 0 128 128 pf_key_supported: 9 15 4 0 128 128 pf_key_supported: 9 15 3 0 32 128 pf_key_supported: 9 15 2 0 128 32 pf_key_supported: 9 15 1 0 32 32 pf_key_supported:10 15 2 0 1 1 + _ + + cd /proc/sys/net/ipsec + egrep ^ debug_ah debug_eroute debug_esp debug_ipc
Re: [leaf-user] subnet-to-subnet simulation problem
On Sunday 29 September 2002 05:08, Vic Berdin wrote: >VPN1-CLI > > |eth0: 192.168.4.1 > |gw:192.168.4.200 > | > | > |eth1: 192.168.4.200 > |gw:192.168.2.1 > > VPN1 BOX >From the look of things, your using Dachstein, so I will assume this. Looks pretty unusual to use eth1 as an external interface, this can bork the networking pretty good with Dachstein in the default setup. > ip_masq_ipsec 7328 0 (unused) DO NOT USE the ipsec module with Dachstein it will bork everything up with the ipsec-kernel. The module is only used for pass-through with Dachstein. > Jul 30 03:42:30 SR3K-VPN1 Pluto[1574]: packet from > 192.168.2.200:61070: initial Main Mode message received on > 192.168.2.1:500 but no connection has been authorized Looks like your keys/naming isn't right in ipsecrets and the point of failure unless having the ipsec module loaded is messing the connection up here (good possibility). -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
Re: [leaf-user] subnet-to-subnet simulation problem
Hello Lynn Avants, 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. TIA - Vic == + egrep -n Starting Pluto /var/log/auth.log + cat + sed -n $s/:.*//p + sed -n 1,$p /var/log/auth.log Jul 30 06:42:07 SR3K-VPN1 Pluto[1737]: Starting Pluto (FreeS/WAN Version 1.91) Jul 30 06:42:07 SR3K-VPN1 Pluto[1737]: including X.509 patch (Version 0.9.3) Jul 30 06:42:07 SR3K-VPN1 Pluto[1737]: Could not change to directory '/etc/ipsec.d/cacerts' Jul 30 06:42:07 SR3K-VPN1 Pluto[1737]: Could not change to directory '/etc/ipsec.d/crls' Jul 30 06:42:07 SR3K-VPN1 Pluto[1737]: could not open my X.509 cert file '/etc/x509cert.der' Jul 30 06:42:07 SR3K-VPN1 Pluto[1737]: OpenPGP certificate file '/etc/pgpcert.pgp' not found Jul 30 06:42:10 SR3K-VPN1 Pluto[1737]: added connection description "VPN1-VPN2" Jul 30 06:42:10 SR3K-VPN1 Pluto[1737]: listening for IKE messages Jul 30 06:42:10 SR3K-VPN1 Pluto[1737]: adding interface ipsec0/eth0 192.168.2.1 Jul 30 06:42:10 SR3K-VPN1 Pluto[1737]: loading secrets from "/etc/ipsec.secrets" 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 Jul 30 06:44:53 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 Jul 30 06:45:33 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 Jul 30 06:46:12 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 + _ + + date Tue Jul 30 06:46:40 UTC 2002 - Original Message - From: "guitarlynn" <[EMAIL PROTECTED]> To: "Vic Berdin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, September 30, 2002 11:57 AM Subject: Re: [leaf-user] subnet-to-subnet simulation problem > On Sunday 29 September 2002 05:08, Vic Berdin wrote: > > >VPN1-CLI > > > > |eth0: 192.168.4.1 > > |gw:192.168.4.200 > > | > > | > > |eth1: 192.168.4.200 > > |gw:192.168.2.1 > > > > VPN1 BOX > > >From the look of things, your using Dachstein, so I will assume this. > Looks pretty unusual to use eth1 as an external interface, this can > bork the networking pretty good with Dachstein in the default setup. > > > ip_masq_ipsec 7328 0 (unused) > > DO NOT USE the ipsec module with Dachstein it will bork everything > up with the ipsec-kernel. The module is only used for pass-through > with Dachstein. > > > > Jul 30 03:42:30 SR3K-VPN1 Pluto[1574]: packet from > > 192.168.2.200:61070: initial Main Mode message received on > > 192.168.2.1:500 but no connection has been authorized > > Looks like your keys/naming isn't right in ipsecrets and the point > of failure unless having the ipsec module loaded is messing the > connection up here (good possibility). > > -- > > ~Lynn Avants > aka Guitarlynn > > guitarlynn at users.sourceforge.net > http://leaf.sourceforge.net > > If linux isn't the answer, you've probably got the wrong question! --- 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
Re: [leaf-user] subnet-to-subnet simulation problem
> 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
Re: [leaf-user] subnet-to-subnet simulation problem
Hello Charles/Everyone, > 1) Why are you loading the ipsec x.509 version of FreeS/WAN when you're > not trying to use certificates? Out of frustration I wish to try out everything and mistakenly backed up ipsec.lrp along with the x.509 binaries. I'm now using the plain ipsec.lrp and tried using both PSK then RSA keying but the problem still lurks. Here are the barfs from the two IPSEC machines. I deaply apologize for this post. But I'm really stumped now. :o( === SR3K-VPN1 Tue Jul 30 12:24:07 UTC 2002 + _ + + ipsec --version Linux FreeS/WAN 1.91 See `ipsec --copyright' for copyright information. + _ + + cat /proc/version Linux version 2.2.19-3-DIGIPH (root@zxivlin) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Tue Sep 24 11:43:46 PHT 2002 + _ + + cat /proc/net/ipsec_eroute 0 192.168.4.0/24 -> 192.168.5.0/24 => %trap + _ + + cat /proc/net/ipsec_spi + _ + + cat /proc/net/ipsec_spigrp + _ + + netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.5.0 192.168.2.200 255.255.255.0 UG0 0 0 ipsec0 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 0.0.0.0 192.168.2.200 0.0.0.0 UG0 0 0 eth0 + _ + + cat /proc/net/ipsec_tncfg ipsec0 -> eth0 mtu=16260(1500) -> 1500 ipsec1 -> NULL mtu=0(0) -> 0 ipsec2 -> NULL mtu=0(0) -> 0 ipsec3 -> NULL mtu=0(0) -> 0 + _ + + cat /proc/net/pf_key sock pid socket next prev e n p sndbfFlags Type St c4f33640 1569 c4f1361000 0 0 2 32767 3 1 + _ + + cd /proc/net + egrep ^ pf_key_registered pf_key_supported pf_key_registered:satype socket pid sk pf_key_registered: 2 c4f13610 1569 c4f33640 pf_key_registered: 3 c4f13610 1569 c4f33640 pf_key_registered: 9 c4f13610 1569 c4f33640 pf_key_registered:10 c4f13610 1569 c4f33640 pf_key_supported:satype exttype alg_id ivlen minbits maxbits pf_key_supported: 2 14 3 0 160 160 pf_key_supported: 2 14 2 0 128 128 pf_key_supported: 3 15 3 128 168 168 pf_key_supported: 3 14 3 0 160 160 pf_key_supported: 3 14 2 0 128 128 pf_key_supported: 9 15 4 0 128 128 pf_key_supported: 9 15 3 0 32 128 pf_key_supported: 9 15 2 0 128 32 pf_key_supported: 9 15 1 0 32 32 pf_key_supported:10 15 2 0 1 1 + _ + + cd /proc/sys/net/ipsec + egrep ^ debug_ah debug_eroute debug_esp debug_ipcomp debug_netlink debug_pfkey debug_radij debug_rcv debug_spi debug_tunnel debug_verbose debug_xform icmp inbound_policy_check tos debug_ah:0 debug_eroute:0 debug_esp:0 debug_ipcomp:0 debug_netlink:0 debug_pfkey:0 debug_radij:0 debug_rcv:0 debug_spi:0 debug_tunnel:0 debug_verbose:0 debug_xform:0 icmp:0 inbound_policy_check:1 tos:1 + _ + + ipsec auto --status 000 interface ipsec0/eth0 192.168.2.1 000 000 "VPN1-VPN2": 192.168.4.0/24===192.168.2.1---192.168.2.200... 000 "VPN1-VPN2": ...192.168.3.200---192.168.3.1===192.168.5.0/24 000 "VPN1-VPN2": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 25%; keyingtries: 0 000 "VPN1-VPN2": policy: RSASIG+ENCRYPT+TUNNEL+PFS; interface: eth0; trap erouted 000 "VPN1-VPN2": newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: #0 000 000 #1: "VPN1-VPN2" STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT in 37s + _ + + ifconfig -a loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:11483 errors:0 dropped:0 overruns:0 frame:0 TX packets:11483 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0 ipsec0Link encap:Ethernet HWaddr 00:04:A7:01:02:48 inet addr:192.168.2.1 Mask:255.255.255.0 UP RUNNING NOARP MTU:16260 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 ipsec1Link encap:IPIP Tunnel HWaddr unspec addr:[NONE SET] Mask:[NONE SET] NOARP MTU:0 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 ipsec2Link encap:IPIP Tunnel HWaddr unsp
Re: [leaf-user] subnet-to-subnet simulation problem
> I'm now using the plain ipsec.lrp and tried using both PSK then RSA
> keying
> but the problem still lurks.
> Here are the barfs from the two IPSEC machines. I deaply apologize for
> this post.
> But I'm really stumped now. :o(
Well, the log messages on both ends look equally cryptic. In general, I
would say you have a problem with configuration. Since both config
files look OK, this likely means a problem with your public keys listed
in /etc/ipsec.conf and your private key in /etc/ipsec.secrets. Since
both these are getting chomped by ipsec barf, and I'm not sure if the
limited LEAF version properly creates key sums, you need to manually
verify you've actually got the right RSA public keys in your
/etc/ipsec.conf file. At this point, I think that's what's causing you
problems, but I can't be sure. If the LEAF version of barf is really
calculating checksums correctly, you *DO* have a mis-match between your
public keys listed in ipsec.conf and the actual keys in ispec.secrets:
> leftrsasigkey=[sums to 364c...]
> rightrsasigkey=[sums to 1636...]
> : RSA {
> # RSA 1024 bits SR3K-VPN1 Mon Sep 9 10:26:23 2002
> # for signatures only, UNSAFE FOR ENCRYPTION
> #pubkey=[sums to 5154...]
Note...doesn't match either *rsasigkey above.
> : RSA {
> # RSA 1024 bits SR3K-VPN1 Mon Sep 9 10:26:39 2002
> # for signatures only, UNSAFE FOR ENCRYPTION
> #pubkey=[sums to 7a9d...]
And neither does this...
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
Re: [leaf-user] subnet-to-subnet simulation problem
On Monday 30 September 2002 09:49, Vic Berdin wrote: > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window > irtt Iface > 192.168.5.0 192.168.2.200 255.255.255.0 UG0 0 > 0 ipsec0 > 192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth1 > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth0 > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 > 0 ipsec0 > 0.0.0.0 192.168.2.200 0.0.0.0 UG0 0 > 0 eth0 > Kernel IP routing table > Destination Gateway Genmask Flags MSS Window > irtt Iface > 192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth1 > 192.168.4.0 192.168.3.200 255.255.255.0 UG0 0 > 0 ipsec0 > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 > 0 eth0 > 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 > 0 ipsec0 > 0.0.0.0 192.168.3.200 0.0.0.0 UG0 0 > 0 eth0 You have shown that eth0 is your internal address and eth1 is your external apparently you haven't fixed everything attempting to run this way since your routing tables on both boxes clearly show that the machine(s) still think eth0 is the default route. In other words, your routing is attempting to run backwards. > conn VPN1-VPN2 > auto=start > type=tunnel > left=192.168.2.1 > leftsubnet=192.168.4.0/24 > leftnexthop=192.168.2.200 > right=192.168.3.1 > authby=rsasig > #authby=secret > leftid=192.168.2.1 > rightid=192.168.3.1 > rightsubnet=192.168.5.0/24 > rightnexthop=192.168.3.200 > leftrsasigkey=[sums to 364c...] > rightrsasigkey=[sums to 1636...] > keyexchange=ike > keylife=8h > keyingtries=0 > pfs=yes > rekeymargin=9m > rekeyfuzz=25% > conn VPN1-VPN2 > auto=start > type=tunnel > left=192.168.2.1 > leftsubnet=192.168.4.0/24 > leftnexthop=192.168.2.200 > right=192.168.3.1 > authby=rsasig > #authby=secret > leftid=192.168.2.1 > rightid=192.168.3.1 > rightsubnet=192.168.5.0/24 > rightnexthop=192.168.3.200 > leftrsasigkey=[sums to 364c...] > rightrsasigkey=[sums to 1636...] > keyexchange=ike > keylife=8h > keyingtries=0 > pfs=yes > rekeymargin=9m > rekeyfuzz=25% Both sides are intending to "start" the connection only one can "start" the connection, the other side(s) must "add". And as Charles noted, nothing will ever be accepted if the checksums of the RSA keys do not match. I would suggest using a secret key first, then going to keys (then certs if desired). Start simple, then make the system more complicated. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
Re: [leaf-user] subnet-to-subnet simulation problem
> Both sides are intending to "start" the connection only one can > "start" the connection, the other side(s) must "add". Actually, this is quite legal, and how I have most of my VPN's setup (the exceptions are the connections where one end has a dynamic IP...you can't start these from the end that doesn't know both IPs!). Typically, I'll set keying retries to a small number on the "more stable" box (ie the Office VPN gateway) so if for any reason it reboots it will restore the connections, but won't keep trying forever (in case one of the home firewalls is off-line), while I set the home-based systems retries to "0", so they'll keep trying to establish a connection as long as they're on-line. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm 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
Re: [leaf-user] subnet-to-subnet simulation problem
- Original Message - From: "Charles Steinkuehler" <[EMAIL PROTECTED]> To: "guitarlynn" <[EMAIL PROTECTED]>; "Vic Berdin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 02, 2002 12:07 AM Subject: Re: [leaf-user] subnet-to-subnet simulation problem > > Both sides are intending to "start" the connection only one can > > "start" the connection, the other side(s) must "add". > > Actually, this is quite legal, and how I have most of my VPN's setup > (the exceptions are the connections where one end has a dynamic IP...you > can't start these from the end that doesn't know both IPs!). > > Typically, I'll set keying retries to a small number on the "more > stable" box (ie the Office VPN gateway) so if for any reason it reboots > it will restore the connections, but won't keep trying forever (in case > one of the home firewalls is off-line), while I set the home-based > systems retries to "0", so they'll keep trying to establish a connection > as long as they're on-line. Yes, and I've looked closely into what Lynn Avant is pointing out about my routes. Well, I don't see anything wrong with it. I repeat that VPN1-CLI can 'ping' VPN2 BOX's 192.168.3.1 external IP. And likewise VPN2-CLI can 'ping' VPN1-BOX 192.168.2.1 external IP. I also allow the two client machines to access our office network and the net via ROUTER's 192.168.1.200 external interface. FWIW, I pasted my routes and traceroute results. Anyway, as an update to my VPN woes, I'm already able to rid off of the md5sum descrepancies pointed out by Charles (the md5sum bin I got is broken). Yet, the same 'trapped' status remains. I also tried using the very latest ipsec kernel patch which is 1.98b againts JNilo's ipsec.lrp v1.97 (not sure if this is OK though, but I'll also rolling one using the latest builds). And still, this 'trapped' status lurks. My desperate approach now is to try to look more closely to my configs and secrets files and also try using an RH7.2 standard distro and learn from it once I get my first tunnel! >From the diagram: VPN1-CLI (Client) |eth0: 192.168.4.1 gw: 192.168.4.200 | |eth1: 192.168.4.200 gw: 192.168.2.1 VPN1 BOX |eth0: 192.168.2.1 gw: 192.168.2.200 | |eth1: 192.168.2.200 gw: 192.168.1.200 ROUTER---eth0: 192.168.1.200 gw: 192.168.1.3 |eth2: 192.168.3.200 gw: 192.168.1.200 | |eth0: 192.168.3.1 gw: 192.168.3.200 VPN2 BOX |eth1: 192.168.5.200 gw: 192.168.3.1 | |eth0: 192.168.5.1 gw: 192.168.5.200 VPN2-CLI (Client) Route tables: VPN1 BOX Kernel IP routing table Destination Gateway Genmask Iface 192.168.5.0 192.168.2.200 255.255.255.0 ipsec0 192.168.4.0 0.0.0.0 255.255.255.0 eth1 192.168.2.0 0.0.0.0 255.255.255.0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 ipsec0 0.0.0.0 192.168.2.200 0.0.0.0 eth0 VPN2 BOX Kernel IP routing table Destination Gateway Genmask Iface 192.168.5.0 0.0.0.0 255.255.255.0 eth1 192.168.4.0 192.168.3.200 255.255.255.0 ipsec0 192.168.3.0 0.0.0.0 255.255.255.0 eth0 192.168.3.0 0.0.0.0 255.255.255.0 ipsec0 0.0.0.0 192.168.3.200 0.0.0.0 eth0 Traceroutes: VPN1 BOX: 'traceroute www.google.com': 1 192.168.2.200 (192.168.2.200) 0.582 ms 0.559 ms 0.543 ms 2 192.168.1.3 (192.168.1.3) 0.697 ms 0.734 ms 0.679 ms 3 202.164.181.237 (202.164.181.237) 2.089 ms 1.812 ms 1.836 ms 4 203.167.82.33 (203.167.82.33) 1.946 ms 11.94 ms 1.968 ms 5 207.176.97.97 (207.176.97.97) 29.38 ms 29.115 ms 29.338 ms 6 207.176.96.65 (207.176.96.65) 32.044 ms 32.725 ms 29.991 ms 7 202.84.143.25 (202.84.143.25) 183.209 ms 187.223 ms 184.571 ms 8 eqixsj-google-gige.google.com (206.223.116.21) 183.135 ms 182.435 ms 187.193 ms 9 core2-0-2-0.pao.net.google.com (216.239.48.213) 185.187 ms 186.571 ms 187.59 ms 10 216.239.48.53 (216.239.48.53) 190.836 ms 189.131 ms 187.449 ms 11 br1-1-3-0.ex.net.google.com (216.239.48.57) 194.241 ms 195.882 ms 195.433 ms 12 exbi2-1-1.net.google.com (216.239.47.6) 202.401 ms 203.635 ms 197.497 ms 13 * * * 14 * * * 15 * * * VPN2 BOX: 'traceroute www.slashdot.org': 1 192.168.3.200 (192.168.3.200) 0.755 ms 0.537 ms 0.525 ms 2 192.168.1.3 (192.168.1.3) 0.733 ms 0.716 ms 0.71 ms 3 202.164.181.237 (202.164.181.237) 1.842 ms 2.695 ms 1.825 ms 4 203.167.82.33 (203.167.82.33) 1.918 ms 1.863 ms 1.835 ms 5 208.172.151.5 (208.172.151.5) 258.009
Re: [leaf-user] subnet-to-subnet simulation problem
> Anyway, as an update to my VPN woes, I'm already able to rid off > of the md5sum descrepancies pointed out by Charles (the md5sum > bin I got is broken). Yet, the same 'trapped' status remains. Hmm...I *KNOW* the ipsec stuff on Dachstein-CD works...I use it in production daily. I agree your routing setup looks OK, and IIRC, your IPChains rules looked acceptable as well. To get past the "trapped" stage and acutally build an SA, all you really need is UDP port-500 traffic between the two machines. Once the SA is in place, any actual traffic will be transmitted using protocol 50 (ESP) or 51 (AH), depending on your config setup. I still think you've got a problem in one (or more) of the four configuation files (2x ipsec.conf & 2x ipsec.secrets). I haven't seen the unabridged contents of these, so I can't say for sure if there is or isn't a problem. I would recommend the following plan of action: 1) Visually compare the contents of your ipsec.conf files with the ipsec.secrets files on both ends to make *SURE* everything matches exactly. If you want, you can send the files to me (or the list) and I'll take a look at them. You will need to regenerate them anyway, as 1024 bit public key encryption is now fairly easy to break using brute-force techniques and a fairly small distributed cluster (ie zombied machines gatherd by script-kiddie hackers, or a system easily put together by a governemnt or mid-sized business)...you should use 2048 bits minimum on any production networks (note this applies to ssh keys, x.509 certificates, and anything else using public key cryptography). 2) If you're still stuck, try re-building both ends from "scratch", starting with a clean version of Dachstein, or at the very least a new ipsec.lrp. Re-create your RSA keys, and re-build your ipsec.conf and ipsec.secrets files. 3) If that doesn't work, it's time to start tracking packets through the network if you haven't done so already. Track the UDP port-500 traffic through your network with ipchains logging rules, a traffic sniffer, or whatever is handy. Verify nothing is happening to the packets (like masquerading) on their trip between the two hosts. 4) If you're *STILL* not going, you'll probably have to enable debugging, and plead to the FreeS/WAN list gurus for help interperting the results :-( 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
Re: [leaf-user] subnet-to-subnet simulation problem
Hello Charles, Lynn, everyone! And well enough!! A tunnel is UP! Both clients from end-to-end can ping each other. Thanks for all your help! I fixed a bit of chaining rules and followed the 2048 sigkey regeneration recommended by Charles. I did almost nothing on the ipsec confs, but replace the new keys and the secrets files. After a restart! I went: "WOW! SO THIS IS WHAT A TUNNEL LOOKS LIKE" I'm just so happy :o. My next venture is a LEAF/DS --- WIN2K VPN *sigh* ... I get this feeling you guys will hear from me soon. heheh. Thanks again! Charles/Lynn/Everyone! - 'ipsec look' on SR3K-VPN1 Thu Oct 3 20:10:14 UTC 2002 - SR3K-VPN1 Thu Oct 3 20:10:36 UTC 2002 192.168.4.0/24 -> 192.168.5.0/24 => [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] (18) ipsec0->eth0 mtu=16260(1427)->1500 [EMAIL PROTECTED] AH_HMAC_MD5: dir=in src=192.168.3.1 ooowin=64 alen=128 aklen=128 life(c,s,h)=add(2857,0,0) [EMAIL PROTECTED] AH_HMAC_MD5: dir=in src=192.168.3.1 ooowin=64 seq=21 bit=0x0001f alen=128 aklen=128 life(c,s,h)=bytes(2180,0,0)add(2850,0,0)use(2543,0,0)packets(21,0,0) idle=720 [EMAIL PROTECTED] AH_HMAC_MD5: dir=out src=192.168.2.1 ooowin=64 alen=128 aklen=128 life(c,s,h)=add(2857,0,0) [EMAIL PROTECTED] AH_HMAC_MD5: dir=out src=192.168.2.1 ooowin=64 seq=18 alen=128 aklen=128 life(c,s,h)=bytes(2344,0,0)add(2850,0,0)use(2543,0,0)packets(18,0,0) idle=1497 [EMAIL PROTECTED] ESP_3DES: dir=in src=192.168.3.1 iv_bits=64bits iv=0x6a06cbef49d98ab0 ooowin=64 eklen=192 life(c,s,h)=add(2857,0,0) [EMAIL PROTECTED] ESP_3DES: dir=in src=192.168.3.1 iv_bits=64bits iv=0x4c2c3b60a4b7f59b ooowin=64 seq=21 bit=0x0001f eklen=192 life(c,s,h)=bytes(1748,0,0)add(2850,0,0)use(2543,0,0)packets(21,0,0) idle=720 [EMAIL PROTECTED] ESP_3DES: dir=out src=192.168.2.1 iv_bits=64bits iv=0xf764e37594b2c2b3 ooowin=64 eklen=192 life(c,s,h)=add(2857,0,0) [EMAIL PROTECTED] ESP_3DES: dir=out src=192.168.2.1 iv_bits=64bits iv=0x6b76781bf9385d32 ooowin=64 seq=18 eklen=192 life(c,s,h)=bytes(1912,0,0)add(2850,0,0)use(2543,0,0)packets(18,0,0) idle=1497 [EMAIL PROTECTED] IPIP: dir=in src=192.168.3.1 life(c,s,h)=add(2857,0,0) [EMAIL PROTECTED] IPIP: dir=out src=192.168.2.1 life(c,s,h)=add(2857,0,0) [EMAIL PROTECTED] IPIP: dir=in src=192.168.3.1 life(c,s,h)=bytes(1748,0,0)add(2850,0,0)use(2543,0,0)packets(21,0,0) idle=720 [EMAIL PROTECTED] IPIP: dir=out src=192.168.2.1 life(c,s,h)=bytes(1548,0,0)add(2850,0,0)use(2543,0,0)packets(18,0,0) idle=1497 Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.2.200 0.0.0.0 UG0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 192.168.5.0 192.168.2.200 255.255.255.0 UG0 0 0 ipsec0 --- 'ipsec auto --status' on SR3K-VPN1 BOX: --- 000 interface ipsec0/eth0 192.168.2.1 000 000 "VPN1-VPN2": 192.168.4.0/24===192.168.2.1---192.168.2.200... 000 "VPN1-VPN2": ...192.168.3.200---192.168.3.1===192.168.5.0/24 000 "VPN1-VPN2": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 "VPN1-VPN2": policy: PSK+ENCRYPT+AUTHENTICATE+TUNNEL+PFS; interface: eth0; erouted 000 "VPN1-VPN2": newest ISAKMP SA: #3; newest IPsec SA: #4; eroute owner: #4 000 000 #2: "VPN1-VPN2" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 25646s 000 #2: "VPN1-VPN2" [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 000 #1: "VPN1-VPN2" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 204s 000 #4: "VPN1-VPN2" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 26135s; newest IPSEC; eroute owner 000 #4: "VPN1-VPN2" [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 000 #3: "VPN1-VPN2" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 935s; newest ISAKMP - 'ipsec look' on SR3K-VPN2 Thu Oct 3 20:10:14 UTC 2002 - 192.168.5.0/24 -> 192.168.4.0/24 => [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] (21) ipsec0->eth0 mtu=16260(1427)->1500 [EMAIL PROTECTED] AH_HMAC_MD5: dir=out src=192.168.3.1 ooowin=64 alen=128 aklen=128 life(c,s,h)=add(2843,0,0) [EMAIL PROTECTED] AH_HMAC_MD5: dir=out src=192.168.3.1 ooowin=64 seq=21 alen=128 aklen=128 life(c,s,h)=bytes(2684,0,0)add(2836,0,0)use(2529,0,0)packets(21,0,0) idle=706 [EMAIL PROTECTED] AH_HMAC_MD5: dir=in src=192.168.2.1 ooowin=64 alen=128 aklen=128 life(c,s,h)=add(2843,0,0) [EMAIL PROTECTED] AH_HMAC_MD5: dir=in src=192.168.2.1 ooowin=64 seq=18 bit=0x3 alen=128 aklen=128 life(c,s,h)=bytes(1912,0,0)add(2836,0,0)use(2529,0,0)packets(18,0,0) idle=1483 [EMAIL PROTECTED] ESP_3DES: dir=out src=192.168.3.1 iv_bits=64
