Comments on: olsr-tunnel https://blog.dd19.de/~alx/2007/12/olsr-tunnel/ freifunk, piratenpartei und polyamorie Sun, 05 Feb 2012 21:07:21 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: alx https://blog.dd19.de/~alx/2007/12/olsr-tunnel/comment-page-1/#comment-739 alx Fri, 20 Jun 2008 14:07:55 +0000 http://blogs.k-ita.de/~alx/?p=28#comment-739 I think the need of more unique ip addresses is not an issue, that is actually the way of building networks, but that is a religious issue in freifunk. ;) The issue of multiple announcements is a logistic "problem", to be solved by the ip address allocation system of the community. The "exposement" of the individual pc is IMHO no problem at all, if there should be no incoming connections allowed, then that is a firewalling issue, not a nat issue. By putting the tunl1 into olsr config, you would just create an assymetric neighbour, as the endpoint has no tunnel back to the node. But: this is just a proof of concept, the implementation of this idea has been done by freifunk leipzig, as they are using nat and policy routing, maybe they solved this issue: http://firmware.leipzig.freifunk.net/ipkg/global/freifunk-gwtun_0.1.2_mipsel.ipk Also, the http://ninux.org people developed an even better way of doing gateway selection, they use loose source routing, with the drawback that all intermediate router need to have this enables, as linux drops this packets silently when they are not explicitly allowed: http://svn.ninux.org/ninuxdeveloping/changeset/496 I think the need of more unique ip addresses is not an issue, that is actually the way of building networks, but that is a religious issue in freifunk. ;)
The issue of multiple announcements is a logistic “problem”, to be solved by the ip address allocation system of the community.
The “exposement” of the individual pc is IMHO no problem at all, if there should be no incoming connections allowed, then that is a firewalling issue, not a nat issue.

By putting the tunl1 into olsr config, you would just create an assymetric neighbour, as the endpoint has no tunnel back to the node.

But:
this is just a proof of concept, the implementation of this idea has been done by freifunk leipzig, as they are using nat and policy routing, maybe they solved this issue: http://firmware.leipzig.freifunk.net/ipkg/global/freifunk-gwtun_0.1.2_mipsel.ipk

Also, the http://ninux.org people developed an even better way of doing gateway selection, they use loose source routing, with the drawback that all intermediate router need to have this enables, as linux drops this packets silently when they are not explicitly allowed: http://svn.ninux.org/ninuxdeveloping/changeset/496

]]> By: Joerg Albert https://blog.dd19.de/~alx/2007/12/olsr-tunnel/comment-page-1/#comment-736 Joerg Albert Fri, 20 Jun 2008 08:35:10 +0000 http://blogs.k-ita.de/~alx/?p=28#comment-736 Interesting article, some time I'll try this. > As packets coming from the LAN port will not pass nat, their answers will not routed back. > To circumvent this, put a small /29 on your lan, switch off NAT and announce the /29 via HNA4. I guess you talk about the node here. Announcing the /29 of your LAN would require more unique IP addresses at the node and could lead to multiple announcing of 192.168.X.X via HNA4. Furthermore the PC at the LAN of the node are exposed to the outside. Adding NAT from the LAN to the tunl1 isn't possible I guess as the packets from the gateway to the node don't pass the tunnel but arrive on the wlan interface. Couldn't we add tunl1 to the olsr controlled interfaces on both the gateway and the node and select among the set of gateways by setting some LQ multiplicators? This would send the packets from the gateway to the node via the tunl1 on the gateway and allow to use NAT. Interesting article, some time I’ll try this.

> As packets coming from the LAN port will not pass nat, their answers will not routed back.
> To circumvent this, put a small /29 on your lan, switch off NAT and announce the /29 via HNA4.

I guess you talk about the node here. Announcing the /29 of your LAN would require more unique IP addresses at the node
and could lead to multiple announcing of 192.168.X.X via HNA4. Furthermore the PC at the LAN of the node are exposed to the outside. Adding NAT from the LAN to the tunl1 isn’t possible I guess as the packets from the gateway to the node don’t pass the tunnel but arrive on the wlan interface.

Couldn’t we add tunl1 to the olsr controlled interfaces on both the gateway and the node and select among the set of gateways by setting some LQ multiplicators? This would send the packets from the gateway to the node via the tunl1 on the gateway and allow to use NAT.

]]>