Charles Steinkuehler wrote: > > Michael D. Schleif wrote: > > > > 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'' > > ???
<snip /> > 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: <snip /> > 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. <snip /> > 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. # pinktrout -- bluetrout ip route change 192.168.1.0/24 via 144.228.51.209 src 192.168.11.254 dev ipsec0 # bluetrout -- pinktrout ### ip route change 192.168.11.0/24 via 64.4.222.158 src 192.168.1.254 dev ipsec0 ip route change 144.228.51.210/32 via 64.4.222.158 src 192.168.1.254 dev ipsec0 The pinktrout cli and that commented-out cli work well on gw-gw tunnels. That one used this time on bluetrout was an attempt to do the equivalent under these different circumstances. I'm going to carefully study what you've just posted and make another attempt later tonight. Thank you . . . -- 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: 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
