switch mode, how to give a public IP behing a NAT
Cédric Lemarchand
cedric.lemarchand at ixblue.com
Thu Mar 22 18:47:24 CET 2012
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 <cedric.lemarchand at ixblue.com
> <mailto:cedric.lemarchand at ixblue.com>>
>
> 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)
>
> 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 list
>> tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>
>> 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 <tel:%2B33%201%2030%2008%2088%2088>
> Mob. +33 6 37 23 40 93 <tel:%2B33%206%2037%2023%2040%2093>
> Fax +33 1 30 08 88 00 <tel:%2B33%201%2030%2008%2088%2000>
> www.ixblue.com <http://www.ixblue.com>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> 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 <http://www.ixblue.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120322/88862a8e/attachment.html>
More information about the tinc
mailing list