Michael D. Schleif 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.Charles Steinkuehler wrote:Michael D. Schleif wrote: > Charles Steinkuehler wrote: >> Regardless, the firewall rules on pinktrout are a >> "Must see", especially given the log errors. > > Simply ipchains -nvL ???Yes, that will work fine. I usually like the output of "net ipfilter list", which also includes port-forwarding settings, but those shouldn't matter here... >> The complete output of "ip addr" and "ip route" from *BOTH* systems >> would also be very helpful. > > ip route is complete in last post; ip addr will go on the webpage, too . > . .<snip /> [1] Now, bluetrout can ping pinktrout; but, what is this ``bad cksum'' ???
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.
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.[2] pinktrout cannot ping bluetrout, nor can I find any errors.
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
Thanks for posting the info...it's a lot easier to debug with everything available.[3] Links: <http://www.helices.org/tmP/bluetrout.txt> <http://www.helices.org/tmP/pinktrout.txt>
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.
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.
NOTE: Looking at your setup, it's possible that masqueraded VPN traffic will work in your existing configuration...I don't know enough about the networking code to know if the IP address used for masquerading comes from the destination interface (in this case, the IP of ipsec0, so things would work), or from the source IP of the route pointing to the interface (in this case 192.168.11.254, so things would be broken).
Looks like you're continuing to make forward progress, and I'm really curious to know how the source IP's of the ipsec0 routes got setup that way. Keep us posted.
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This sf.net email is sponsored by: Are you worried about your web server security? Click here for a FREE Thawte Apache SSL Guide and answer your Apache SSL security needs: http://www.gothawte.com/rd523.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
