[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] inter-site routing stopped by martians


  • Subject: Re: [Openvpn-users] inter-site routing stopped by martians
  • From: Giancarlo Razzolini <linux-fan@xxxxxxxxxxx>
  • Date: Tue, 26 Jul 2005 12:02:53 -0300

lists@xxxxxxxxxxxxxxxxxxxx wrote:
> I'm setting up a multi-site VPN and I've got it mostly working.
> I've got a server on 192.168.0.254, which is a gateway machine, and
> I've connected other gateway machines at 192.168.32.254 and 192.168.33.254.
> 192.168.0.254 has tun0 10.133.0.1
> 192.168.32.254 has tun0 10.133.0.2
> 192.168.33.254 has tun0 10.133.0.6
> 
> The ccd directories push routes between the nets, and server.conf
> advertises routes for 32.0 and 33.0. I think this part is working. I have
> client-to-client declared in server.conf.
> 
> I have 32.254 and 33.254 pinging to 0.254, but when I try to ping from
> 32.254 to 33.254 (thru 0.254 of course), 33.254 logs "martian addresses".
> I've tried "echo 0 > /proc/sys/net/ipv4/tun0/rp_filter" but that doesn't
> seem to allow routing, it just stops logging.
> 
> Example from messages on 33.254:
>   martian source 192.168.33.254 from 10.133.0.2, on dev tun0
> 
> Is this something that I take care of in 33.254's iptables using
> masquerading? Or do I have to turn of rp_filtering on the internal
> interfaces as well? Or something else?
> 
> The only funny thing I see in the routes on 0.254 is that the
> various gateways seem to be set to 10.133.0.2:
> 10.133.0.2      *               255.255.255.255 UH    0      0        0 tun0
> 192.168.36.0    10.133.0.2      255.255.255.0   UG    0      0        0 tun0
> 192.168.34.0    10.133.0.2      255.255.255.0   UG    0      0        0 tun0
> 66.114.140.0    *               255.255.255.0   U     0      0        0 eth0
> 192.168.35.0    10.133.0.2      255.255.255.0   UG    0      0        0 tun0
> 192.168.32.0    10.133.0.2      255.255.255.0   UG    0      0        0 tun0
> 192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
> 192.168.33.0    10.133.0.2      255.255.255.0   UG    0      0        0 tun0
> 10.133.0.0      10.133.0.2      255.255.255.0   UG    0      0        0 tun0
> default         pia140-1.pionee 0.0.0.0         UG    0      0        0 eth0
> 
> Could this be my problem? These are the routes I'm advertising in
> server.conf:
> push "route 192.168.0.0 255.255.255.0"
> route 10.133.0.0 255.255.255.0
> route 192.168.32.0 255.255.255.0
> route 192.168.33.0 255.255.255.0
> route 192.168.34.0 255.255.255.0
> route 192.168.35.0 255.255.255.0
> route 192.168.36.0 255.255.255.0
> 
> TIA,
> 
> Jed
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 
I believe that you will have to deactivate the rp_filtering end the
log_martians on your kernel. The rp_filtering do a source check on the
ip address, and the ip addresses that your interface are receiving
aren't on their subnet. Try only deactivating the log_martians. That
should work. If you deactivate, log_martians, and it still won't work,
Ttry increasing the log level of the kernel with an dmesg -n 8. If it
isn't logging anything, and still don't work, it's almost sure that your
packets are being dropped by the rp_filtering. I don't why it doesn't
log anything, but i had some headaches because of it.

-- 
Giancarlo Razzolini
Linux User 172199
Moleque Sem Conteudo Numero #002
Slackware Current
Snike Tecnologia em Informática
4386 2A6F FFD4 4D5F 5842  6EA0 7ABE BBAB 9C0E 6B85

Attachment: signature.asc
Description: OpenPGP digital signature