Charles Steinkuehler wrote:
>
> Michael D. Schleif wrote:
> >
> > Charles Steinkuehler wrote:
> >>
> >> Michael D. Schleif wrote:
> >> >
> >> > Charles Steinkuehler wrote:
<snip />
> 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.
> 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
> > [2] pinktrout cannot ping bluetrout, nor can I find any errors.
>
> As expected with a host-subnet VPN. I'm actually quite suprised that
> your pings from bluetrout make it to pinktrout across the
> VPN...normally, the pings would leave with the source IP of the external
> interface, which does *NOT* match the host-subnet VPN you are setting up.
>
> This this works at all is apparently due to the fact that your source IP
> for the VPN routes is *NOT* the same as your external IP on either
> box...note the src setting in the snipped ip rotue output below:
>
> root@bluetrout:/root
> # ip route
> 144.228.51.210 via 64.4.222.158 dev ipsec0 src 192.168.1.254
>
> root@pinktrout:/root
> # ip route
> 192.168.1.0/24 via 144.228.51.209 dev ipsec0 src 192.168.11.254
>
> This is actually a good thing on the bluetrout side, and enables packets
> generated on bluetrout destined for pinktrout to go thorugh the VPN. On
> the pinktrout side, however, the same setup is a bad thing...since the
> VPN is host-subnet, packets generated on pinktrout will *NOT* travel
> thorugh the VPN, since their source IP will not match the tunnel
> description. Instead, these packets will simply disappear...as
> previously mentioned, packets hitting an ipsec interface that do not
> match an established SA are silently dropped.
>
> I can only assume you've created a custom up_down script, or otherwise
> added advanced routing commands to play with the source address field as
> the IPSec routes get built (when VPN tunnels are established/destroyed).
> My IPSec routes all have a source IP that matches the IP of the ipsec0
> interface (which is the same as my external IP). In other words:
>
> External IP = ipsec0 IP = dev ipsec0 route source IP
As stated, I have removed these -- too complicated at this point?
> > [3] Links:
> >
> > <http://www.helices.org/tmP/bluetrout.txt>
> > <http://www.helices.org/tmP/pinktrout.txt>
Both links have new, dated material at bottom.
> Thanks for posting the info...it's a lot easier to debug with everything
> available.
>
> 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.
So, once again, I goto sleep stumped ;<
> 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 . . .
Other ideas?
<snip />
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
-------------------------------------------------------
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
