switch mode, how to give a public IP behing a NAT

Thu Mar 22 19:29:03 CET 2012

2012/3/22 Cédric Lemarchand <cedric.lemarchand at ixblue.com>

>  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>
>
>>  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 listtinc at tinc-vpn.orghttp://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
>> tinc at tinc-vpn.org
>> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>>
>>
>
>
> _______________________________________________
> tinc mailing listtinc at tinc-vpn.orghttp://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
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20120322/678136b2/attachment-0001.html>