Below are my routes on both left and right sides. Charles, if you can confirm them correct, I think there must be some rule on my left-side denying packets destined for 192.168.1 even reach left-side eth0.
I accidentally found this in one old log: Apr 23 19:14:06 router kernel: Packet log: input DENY eth0 PROTO=1 192.168.1.2:3 24.83.28.213:3 L=56 S=0x00 I=36609 F=0x0000 T=109 (#10) But I must say that I do not know if ipsec was run at that time And the rule 10 in input chain is: 10 0 0 DENY all ----l- 0xFF 0x00 eth0 192.168.0.0/16 0.0.0.0/0 n/ On left side (internal 192.168.9, wants to talk to 192.168.1 via ipsec) # ip route 192.168.3.0/24 dev eth3 proto kernel scope link src 192.168.3.254 192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.254 192.168.1.0/24 via 24.83.28.1 dev ipsec0 192.168.9.0/24 dev eth1 proto kernel scope link src 192.168.9.254 24.83.28.0/22 dev eth0 proto kernel scope link src 24.83.28.213 24.83.28.0/22 dev ipsec0 proto kernel scope link src 24.83.28.213 default via 24.83.28.1 dev eth0 router: -root- # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.3.0 * 255.255.255.0 U 0 0 0 eth3 192.168.2.0 * 255.255.255.0 U 0 0 0 eth2 192.168.1.0 24.83.28.1 255.255.255.0 UG 0 0 0 ipsec0 192.168.9.0 * 255.255.255.0 U 0 0 0 eth1 24.83.28.0 * 255.255.252.0 U 0 0 0 eth0 24.83.28.0 * 255.255.252.0 U 0 0 0 ipsec0 default 24.83.28.1 0.0.0.0 UG 0 0 0 eth0 and right side (internal 192.168.1, wants to talk to 192.168.9 via ipsec): # ip route 192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.254 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.254 192.168.9.0/24 via 24.76.92.1 dev ipsec0 24.76.92.0/22 dev eth0 proto kernel scope link src 24.76.93.9 24.76.92.0/22 dev ipsec0 proto kernel scope link src 24.76.93.9 default via 24.76.92.1 dev eth0 router: -root- # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.2.0 * 255.255.255.0 U 0 0 0 eth2 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 192.168.9.0 24.76.92.1 255.255.255.0 UG 0 0 0 ipsec0 24.76.92.0 * 255.255.252.0 U 0 0 0 eth0 24.76.92.0 * 255.255.252.0 U 0 0 0 ipsec0 default 24.76.92.1 0.0.0.0 UG 0 0 0 eth0 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Charles Steinkuehler Sent: Thursday, April 25, 2002 7:46 AM To: Jonathan French Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Leaf-user] VPN error, please help From: "MLU " <[EMAIL PROTECTED]> > I strongly hope that's my mistake somewhere and not the ISP's. If the ISP blocks the IPSEC, could I connect to my office's VPN server? I still can do that before this experiment (removing ipsec module...). > > The bad (and probably good -:)) news is that I do not see anything logged into /var/log/messages on my site after I ping the other site. > > Lynn mentioned that "But more likely, the route to the correct local subnet on each machine is missing" . How can I detect that and how to fix it. Look at your local routing setup (ip route or netstat -nr). Make sure there is a route directing packets destined for the far end of the VPN to the ipsec device. From: "Jonathan French" <[EMAIL PROTECTED]> > I'm having similar problems, and have found this thread helpful. I've > been wondering, do we have to declare the routing on the gateways, or > shouldn't ipsec handle this? FreeS/WAN handles setting up routes for the VPN link (ie traffic to the far end of the VPN gets routed to ipsec0), but you still have to setup basic networking (including routing) on the VPN gateway, as well as duplicate some routing information in FreeS/WAN's configuration file (due to limitations with the 2.0 series kerenl, initial versions of FreeS/WAN were unable to use the kernel's routing information, so this had to be duplicated in the FreeS/WAN configs...this will be fixed in the next major re-write of KLIPS, the kernel IPSec code). > Also, what if the ipsec router is not the > default gateway for a machine that you are trying to ping from > elsewhere? Do the pings try to return through the wrong router? If the VPN gateway is *NOT* the default router for the subnet, EACH AND EVERY HOST that wants to talk to the remote end of the VPN needs a static route directing those packets to the VPN gateway. Your life will be *MUCH* easier if the VPN gateway is also the default gateway for your subnet. If you are required to use an alternate firewall for some reason, you may find a "series" configuration might work better than trying to parallel the VPN gateway and your existing firewall, ie: internet | firewall | VPN Gateway | internal network Rather than: internet | +----------\ | | firewall VPN Gateway | | +----------/ | internal network If your firewall is "fancy" enough, you may also be able to setup something like: internet | firewall --- VPN Gateway | internal network Where you add a static route to the firewall (forwarding internal network -> VPN traffic to the VPN gateway), and port-forward, NAT, or otherwise route inbound IPSec traffic to the VPN gateway box, as well. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
