Charles Steinkuehler wrote: > > Michael D. Schleif wrote: > > I am confused ;< > > > > In order to address the original vpn problem, we have setup a pilot vpn > > between two (2) of our DCD's. > > > > How does this scenario qualify as ``martian'' ??? > > > > root@bluetrout:/root > > # tail -f /var/log/kern.log > > Nov 11 22:08:09 bluetrout kernel: martian source d233e490 for 9dde0440, > > dev wan1 > > Nov 11 22:09:29 bluetrout last message repeated 2 times > > Nov 11 22:09:59 bluetrout last message repeated 2 times > > Nov 11 22:11:19 bluetrout last message repeated 2 times > > Nov 11 22:13:19 bluetrout kernel: martian source d233e490 for 9dde0440, > > dev wan1 > > Nov 11 22:14:29 bluetrout last message repeated 10 times > > Nov 11 22:15:19 bluetrout last message repeated 6 times > > Nov 11 22:16:37 bluetrout last message repeated 7 times > > Nov 11 22:17:19 bluetrout last message repeated 5 times > > Nov 11 22:18:37 bluetrout last message repeated 7 times > > Nov 11 22:19:19 bluetrout last message repeated 5 times > > Nov 11 22:20:37 bluetrout last message repeated 7 times > > Nov 11 22:21:19 bluetrout last message repeated 5 times > > > > NOTE: > > 9dde0440 == 64.4.222.157 > > d233e490 == 144.228.51.210 > > (wan1 on other side of vpn) > > > > > > # ip addr > > 1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > inet 127.0.0.1/8 brd 127.255.255.255 scope global lo > > 2: ipsec0: <NOARP> mtu 16260 qdisc pfifo_fast qlen 10 > > link/ipip > > inet 64.4.222.157 peer 64.4.222.158/32 scope global ipsec0 > > . . . > > 7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > > link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff > > inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 > > 8: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > > link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff > > inet 64.4.197.65/26 brd 64.4.197.127 scope global eth1 > > 14: wan1: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100 > > link/ppp > > inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1 > > inet 64.4.197.99/32 scope global wan1 > > inet 64.4.197.100/32 scope global wan1 > > inet 64.4.197.101/32 scope global wan1 > > > > > > Every time that I think that I understand what constitutes martian-ness, > > I am tossed a new wrinkle ;> > > > > What do you think? > > You don't give enough information to correctly diagnose martian errors, > which are based pretty much entirely on the status of the route tables. > Also, while I have not done a lot of host-host or host-subnet VPNs > (you also don't include your IPSec configuration), you will run into > problems with these VPN flavors if you don't have rpfiltering turned off > (you'll get a warning when starting IPSec about this if it's enabled).
Yes, I know that I did not include ipsec info; but, I fail to see any relevancy. Isn't martian-ness independent of anything ipsec? What I see here is a valid public address trying to come in the publicly addressed external interface of a router. My question, I feel, remains valid: How can this be considered martian? Clearly, in order for me to understand this, I need a better grasp of martian-ness. Pointers? Docs? -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ 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
