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

Donald Pearson donaldwhpearson at gmail.com
Thu Mar 22 17:09:30 CET 2012


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..

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.

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.

>   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 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.

>
>  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
> 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/904ac4f6/attachment-0001.html>


More information about the tinc mailing list