Michael D. Schleif wrote:
Charles Steinkuehler wrote:A couple problems here. First, you're trying to ping between the two hosts. This is not supported (without advanced routing rules) when you have a host-subnet VPN. Please try pinging pinktrout from a host *BEHIND* bluetrout, rather than bluetrout itself.I have now removed all advanced routing rules and posted results of ping tests from hosts on both sides that are hosts _within_ each opposing network.
Two steps forward, and one step back...or is that the other way around :)
That should work better...note that the latest 3.7 version looks to contain a lot of improvements for ipsec over 3.6 (at least according to the changelog). Note that there are trojened versions of the source for 3.7 floating around...make sure the version you use is clean, if you try to upgrade.Second, I think your tcpdump is wacked. In addition to the checksum error, there are several other problems (note that pretty much everything about the ping reply looks like garbage). This is a known side effect of earlier versions of tcpdump when run on ipsec interfaces. You will need to get a recent tcpdump if you want to watch clear-text packets on the ipsec0 interface...the FreeS/WAN documentation has more info on exactly what the problem is, and which versions of tcpdump work properly.I have a good tcpdump; but, apparently, it was not on that box ;< All subsequent tcpdumps will be based on this: # tcpdump --version tcpdump version 3.6 libpcap version 0.4a6
> [3] Links: > > <http://www.helices.org/tmP/bluetrout.txt> > <http://www.helices.org/tmP/pinktrout.txt>Both links have new, dated material at bottom.It looks like if you fix the source IP problem on the ipsec routes, your VPN link will be up & running. With that going, you should be able to test connection of the private networks behind pinktrout via masquerading (to pinktrout's external IP) and then through the VPN tunnel.At this time, neither host interior to either network can ping a host inside the opposing network.
...as expected, see below.
So, once again, I goto sleep stumped ;<
...but at least you still have time to sleep, so it can't be all that bad ;>
At this point, I don't think anything is broken, but I'm not sure you correctly understand how it is supposed to work.NOTE: I would probably add the ipsec0 interface to the masquerade rule for VPN traffic, but with fully specified source & destination networks, that probably doesn't matter.For now, I have also removed my first stab at this. So, now both ipchains and ip route should be standard DCD . . .
You should have a host-subnet VPN, linking pinktrout's public IP with the 192.168.1.0/24 behind bluetrout. With no advanced routing rules and no masquerade rules in place, you will *NOT* be able to communicate either between host-host (pinktrout - bluetrout) or subnet-subnet (192.168.11.0/24 - 192.168.1.0/24). You will *ONLY* be able to ping between host-subnet (pinktrout - 192.168.1.0/24), and systems on the 192.168.1.0/24 side must be behind the bluetrout router (ie not bluetrout itself).
So...try pinging from pinktrout to machines on the 192.168.1.0/24 network (and vice-versa), which should work.
Once you can accomplish the above pings, you need to add masquerading rules so traffic from the 192.168.11.0/24 network gets masqueraded behind pinktrout's public IP, and routed across the VPN...something like:
ipchains -I input -j MASQ -s 192.168.11.0/24 -d 192.168.1.0/24 -i ipsec0
At this point, you should be able to ping 192.168.1.0/24 network systems from systems on the 192.168.11.0/24 behind pinktrout. You should also be able to ping pinktrout's public IP from systems behind bluetrout, with all traffic going through the VPN.
IMPORTANT: At *NO TIME* will you be able to directly ping (or otherwise talk to) any systems behind pinktrout from systems behind bluetrout, due to the masquerading rules in place. As far as the systems behind bluetrout are concerend, they are communicating with one, and only one, IP, which is the public IP of pinktrout. In other words, the systems behind pinktrout are hidden from the systems behind bluetrout the same way all internal networks are hidden from the internet in general by a masquerading firewall.
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
------------------------------------------------------------------------
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
