[OpenWireless Tech] No probl/ which VPN

Eugene Smiley eug.smiley at gmail.com
Wed Nov 7 08:28:12 PST 2012


Missed a few directly related to OpenVPN with firewall rules:
http://wiki.openwrt.org/inbox/vpn.howto
https://forum.openwrt.org/viewtopic.php?id=35021



On Wed, Nov 7, 2012 at 11:15 AM, Eugene Smiley <eug.smiley at gmail.com> wrote:

> Tabs that I currently have open on the topic, all OpenWRT specific:
> http://wiki.openwrt.org/doc/recipes/guest-wlan
> https://forum.openwrt.org/viewtopic.php?id=28317
> https://forum.openwrt.org/viewtopic.php?id=28926
>
> http://jwalanta.blogspot.com/2012/03/multiple-ssid-on-openwrt-with-bandwidth.html
>
>
>
> On Wed, Nov 7, 2012 at 5:27 AM, "Andy Green (林安廸)" <andy at warmcat.com>wrote:
>
>> On 11/07/12 15:38, the mail apparently from Natanael included:
>>
>>
>>  https://play.google.com/store/**apps/details?id=de.blinkt.**openvpn<https://play.google.com/store/apps/details?id=de.blinkt.openvpn>
>>>
>>> Root free OpenVPN for Android!
>>>
>>
>> Very cool, I didn't know about that.  Thanks for pointing it out.
>>
>>
>>  I'll just say this: No VPN or other proxy + untrusted routers = only a
>>> minor security advantage against active attackers over the current way
>>> of doing things. (Though much more secure against passive attackers, but
>>> active attacks are easy on WiFi.)
>>>
>>> Please, go with VPN:s of some sort. As I suggested before, put a link in
>>> the client to a database over trusted VPN:s, including free ones. Let it
>>> pick one from there.
>>>
>>
>> Right, but we probably need a reference implementation.
>>
>> It seems that the "Tomato" firmware might do
>>
>> http://www.polarcloud.com/**tomato <http://www.polarcloud.com/tomato>
>>
>> someone mentioned in the comments for the Android openvpn client they had
>> connected to openvpn server running on that using the Android client.  And
>> that runs on a bunch of cheap and widely-available routers.
>>
>> Or if anyone has a better idea, let us know.
>>
>> The bit of magic that's missing is being able to run a completely normal
>> WPA network and this unencrypted one at the same time.  I think how to do
>> that (and if it's possible) will depend on the chipset a lot and might
>> require AP vendor manufacturer cooperation.
>>
>> But Tomato+cheap Broadcomm router looks like it could become a
>> plug-and-play add-on type reference platform, plug it into the
>>
>> The missing work would be netfilter rules to restrict the WLAN interface
>> to stateful VPN traffic only.
>>
>> Looking here
>>
>> https://community.openvpn.net/**openvpn/browser/sample-config-**
>> files/firewall.sh?rev=**2d4e7685cd1a6d8e1eb1befa241b75**95809d3b45<https://community.openvpn.net/openvpn/browser/sample-config-files/firewall.sh?rev=2d4e7685cd1a6d8e1eb1befa241b7595809d3b45>
>>
>> We need something like
>>
>> iptables -A INPUT -i wlan0 -j DROP
>> iptables -A INPUT -i wlan0 -p udp --dport 1194 -j ACCEPT
>> iptables -A INPUT -i wlan0 -d 10.0.0.0/8 -p udp -j DROP
>> iptables -A INPUT -i wlan0 -d 192.168.0.0/16 -p udp -j DROP
>> iptables -A INPUT -i wlan0 -d 172.16.0.0/12 -p udp -j DROP
>>
>> However iptables can do stateful VPN inspection which is probably better,
>> I have no idea how to do it though.
>>
>> While it's not built-in to his main ISP home router, he'll also need to
>> put its local network address as forwarded for UDP 1194 or just name it as
>> in the DMZ.
>>
>> Then, if it's configured for wlan0 unencrypted with an ssid like
>> "fvo-myap" (Free Vpen-Only), people should be able to walk up to it with
>> their phone and get a vpn link to their server.  At the same time, it acts
>> as the VPN server for the AP owner.  That's quite a lot of the plan
>> implemented.
>>
>> -Andy
>>
>>  Den 7 nov 2012 07:54 skrev Andy Green (林安廸) <andy at warmcat.com
>>> <mailto:andy at warmcat.com>>:
>>>
>>>
>>>     On 11/07/12 12:29, the mail apparently from John Gilmore included:
>>>
>>>             Brad> How many people are willing to be the Kent State
>>>             victims...
>>>
>>>             Brad> Feel free to put your money where your mouth is and
>>>             actively go
>>>             Brad> out and seek UC Davis or Kent State type experiences
>>>             and then
>>>             Brad> report back to us how well this works for you to
>>> encourage
>>>             Brad> others to do the same.  We'll wait.
>>>
>>>
>>>         No need to wait.  I've been running one or more open wireless
>>>         networks
>>>         on and in my house for many years.  I had one on my roof back
>>>         when it
>>>         was called "802.11b" instead of WiFi -- when you could actually
>>>         hear a
>>>         signal from blocks away.  (Now there's so much other WiFi traffic
>>>         nearby that I can't see my access points from more than a few
>>> houses
>>>         away.)
>>>
>>>         So far nobody has sued me, broken into my house, tried to shut
>>> down
>>>         my internet access, etc.  Of course, I exercise discretion in
>>>         choosing
>>>         my ISPs - I'm not on one that claims I can't run servers or
>>> access
>>>         points.
>>>
>>>
>>>     Enough people have gotten into problems that it is now widely
>>>     understood to be "dangerous and unwise".  I'm not saying it is,
>>>     actually I think what you are doing is great.  However that's what
>>>     the man in the street thinks and he has put WPA screens around his
>>>     AP because of it.
>>>
>>>         Any device should be able to connect without authorization, and
>>>         immediately pass real, unfiltered Internet traffic.  If your
>>>         pedometer
>>>
>>>
>>>     Agree with this... I don't like the monetization ideas at all.  If
>>>     it's going to be offered, it should be as near zero hassle as
>>> possible.
>>>
>>>         wants to report your jogging time, or your camera wants to
>>>         upload the
>>>         three pictures you took before you wandered into open WiFi
>>> range, it
>>>         should work.  These apps should all be supported without manual
>>>         intervention.
>>>
>>>
>>>     Right...
>>>
>>>         I think we should put our attention on solving some of the real
>>>         problems in open access wireless, such as its susceptibility to
>>>         radio-link wiretapping, its lack of ease of configuration, and
>>>         do some
>>>         negotiation with ISPs to improve their terms.  Forcing every open
>>>         wireless node down a VPN strikes me as a lot of work that
>>> somebody
>>>         else could do later, or "maybe never".  For example, it would
>>>         require
>>>         protocol changes in every client device.  Real "open wireless"
>>> would
>>>         work with unmodified client devices.
>>>
>>>
>>>     I think those things are orthogonal, they can and maybe should be
>>>     done but they don't really change the VPN-only advantages.
>>>
>>>
>>>     You're right it's just talk right now.  To move it on we need to
>>>     beat out some consensus leading to a short specification document
>>>     for what it is and how it works.  If the EFF are behind it, we can
>>>     probably get introductions to the major router manufacturers and
>>>     their input to improve it.
>>>
>>>     One problem is what VPN protocol... Android does not support the
>>>     obvious one OpenVPN out of the box.  It looks like OpenSwan is
>>>     needed?  Does that make trouble on other platforms, eg, Apple or
>>> MSFT?
>>>
>>>     -Andy
>>>
>>>     ______________________________**___________________
>>>     Tech mailing list
>>>     Tech at srv1.openwireless.org <mailto:Tech at srv1.**openwireless.org<Tech at srv1.openwireless.org>
>>> >
>>>     https://srv1.openwireless.org/**__mailman/listinfo/tech<https://srv1.openwireless.org/__mailman/listinfo/tech>
>>>     <https://srv1.openwireless.**org/mailman/listinfo/tech<https://srv1.openwireless.org/mailman/listinfo/tech>
>>> >
>>>
>>>
>> ______________________________**_________________
>> Tech mailing list
>> Tech at srv1.openwireless.org
>> https://srv1.openwireless.org/**mailman/listinfo/tech<https://srv1.openwireless.org/mailman/listinfo/tech>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20121107/9858f5d4/attachment.html>


More information about the Tech mailing list