2012/3/22 Cédric Lemarchand <[email protected]> > Le 22/03/12 17:09, Donald Pearson a écrit : > > Cédric. > > When you say GATE, do you mean "GATE/NAT" or "GATE/PUB" ? > > 2012/3/22 Cédric Lemarchand <[email protected]> > >> Le 22/03/12 12:29, Guus Sliepen a écrit : >> >> Video (V1) <==> Node 1 (N1) <=GATE / NAT=> WWW <=GATE / PUB=> Node 2 (N2) >> >> V1 has fixed public IP in the range of N2, and the ip of GATE has >> default gateway. >> >> Hm, but if you want any host on the internet to be able to reach V1, the >> default gateway for V1 should be N2, not GATE. >> >> This is the goal yes. >> >> "N2" and "GATE PUB" are on the same public range, GATE is the default >> gateway for this public subnet, as i try to extend the ethernet segment of >> this subnet, V1 should has this default gateway too, right ? >> > > I think you mean "gate/pub" here.. > > Yes. > > > Only if you want V1 to use gate/pub to reach the internet. V1 will > still need it's own "normal" gateway in order for the VPN to be established > over the internet so you will at least need a /32 route for N2's IP address > to use V1's "normal" gateway. Unless you have a very good reason, you will > also want V1 to continue to use it's normal gateway to reach other nodes on > the internet. You probably want V1 to use the VPN only for access to N2's > subnet. > > The VPN is established by N1 via its interface eth0, providing the > ethernet VPN on its interface eth1 (which is bridged with the tinc > interface). V1 only "see" the provided ethernet segment by N1, and got is > interface directly configured with a fixed public IP, and the default > gateway "GATE PUB" (the provider's gateway for this publix subnet) > > Oh I see, sorry that I missed the detail that N1 owns the Tinc interface. So yes the Tinc interface on N1 should be bridged with eth1. N1's eth1 should have a physical connection to V1, either directly or through a switch. If V1 has no other interfaces, and you don't want to multi-home its interface, and you do want it to be able to route out to the internet; Yes it will need to use the IP of gate/pub for its default gateway.
So network configurations should look something like this? V1: Eth0 1.0.0.1/24 <-- vpn participating, default route 1.0.0.254 (but not necessary) N1: Eth0 10.10.10.1 <-- default route 10.10.10.254 Br0 1.0.0.2/24 <-- vpn participating - eth1 - tinc Gate/Nat: Eth0 10.10.10.254 Eth1 1.2.3.4 (provided by ISP) ------- internet -------- Gate/Pub: Eth0 1.0.0.254/24 N2: Br0 1.0.0.3/24 <-- vpn particpating, default route 1.0.0.254 - eth0 - tinc > So, V1 will have an interface on the same subnet has gate/nat and it's > default gateway will be gate/nat. V1 will also have a tinc interface on > the same subnet as N2. Now, if you are trying to extend N2's subnet to > multiple node's at V1's physical location, then you will have a 2nd > interface on V1, bridged with the tinc interface, and the bridge interface > (as well as the interfaces of any other nodes in V1's physical location > that you wanted to participate in the VPN) will have an IP on N2's subnet. > > Like i have tried to explain before, the VPN is established by N1, not V1. > V1 has only one interface with the fixed public IP. > > N1 has eth0 on the lan, br0 is a bridge of eth1 (where i want to plug >> the video device) and the tinc interface. >> N2 has is public IP on br0, which is a bridge of eth0 and the tinc >> interface. >> >> [...] >> >> When i try to ping GATE from V1, i can see arp request crossing the VPN >> (on both br0 interfaces), packet capture on GATE show the arp reply, but >> this arp reply never come back on the bridge br0 of N2. (N2 is using >> GATE has default gateway too) >> >> I think that is normal. The ARP request is a broadcast packet, so you should >> see that on all the interfaces. But the ARP reply is a unicast packet, so it >> is >> only sent to V1. The bridge on N1 should therefore not forward it to the VPN >> interface, so N2 will never see this ARP reply. >> >> Ok, but the thing is i dont anderstand is even if the ARP reply is >> unicast, it should cross the VPN to go back to the machine that request it >> ? (i use packet capture on promiscuous mode on the bridge, so i should see >> it) >> > > Yes you should. > > Ok. > > >> But you seem to be implying that you cannot ping GATE from V1. It would >> help if >> you could show is the routing tables on V1, N1 and N2, and which IP addresses >> V1 and GATE have. >> >> Has i said, V1 is on the same ethernet segment / same subnet provided >> by the VPN, so if i am right, routing cannot be a part of the problem, the >> only needed routes are local and default gateway. >> > > When everything works, yes. V1 and N2 will "see" each-other as members > of the same LAN, however we're still doing this over the internet so plenty > of routing is still involved and needs to be correct. :) > >> >> >> >> _______________________________________________ >> tinc mailing >> [email protected]http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> >> >> >> -- >> Cédric Lemarchand >> System & Network Engineer >> iXBlue >> 52, avenue de l'Europe >> 78160 Marly le Roi >> France >> Tel. +33 1 30 08 88 88 <%2B33%201%2030%2008%2088%2088> >> Mob. +33 6 37 23 40 93 <%2B33%206%2037%2023%2040%2093> >> Fax +33 1 30 08 88 00 <%2B33%201%2030%2008%2088%2000> >> www.ixblue.com >> >> _______________________________________________ >> tinc mailing list >> [email protected] >> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> >> > > > _______________________________________________ > tinc mailing > [email protected]http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > > > > -- > Cédric Lemarchand > System & Network Engineer > iXBlue > 52, avenue de l'Europe > 78160 Marly le Roi > France > Tel. +33 1 30 08 88 88 > Mob. +33 6 37 23 40 93 > Fax +33 1 30 08 88 00 > www.ixblue.com > > _______________________________________________ > tinc mailing list > [email protected] > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
