[Cerowrt-devel] vpn fw question

[Cerowrt-devel] vpn fw question

[Eric S. Johansson]

I was trying to setup my cerowrt box as an openvpn client. everything 
seems to be working. The VPN link comes up, tun0 is created. I can 
access machines on the far end of the link from the AP and vice versa. 
the openwrt incantation for the vpn says to create an interface called vpn0

network.vpn0=interface
network.vpn0.proto=none
network.vpn0.ifname=tun0

ifconfig says  tun0 exists  but no vpn0. fw3 reload says:

Warning: Section @zone[1] (lan) cannot resolve device of network 'lan'
Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'

sometimes it says: Warning: Section @zone[1] (lan) cannot resolve device 
of network 'vpn0'

tcpdump sees the ICMP request at se00 and tun0 but not at the remote 
target. this leads me to believe that it's probably a firewall problem 
but I don't know where the logs are.

This brings me to one of the problem with had making changes in cerowrt, 
namely, how the $##$& do you debug this thing? I've had to reflash this 
box way too many times because I did something that effectively bricked 
it. right now, I would settle for knowing where to find where logs are put.

thanks
--- eric

Re: [Cerowrt-devel] vpn fw question

[Dave Taht]

On Thu, Oct 2, 2014 at 6:32 PM, Eric S. Johansson <esj@eggo.org> wrote:
> I was trying to setup my cerowrt box as an openvpn client. everything seems
> to be working. The VPN link comes up, tun0 is created. I can access machines
> on the far end of the link from the AP and vice versa. the openwrt
> incantation for the vpn says to create an interface called vpn0
>
> network.vpn0=interface
> network.vpn0.proto=none
> network.vpn0.ifname=tun0

You just add the appropriate commands to /etc/config/openvpn,
or so I thought.

>
> ifconfig says  tun0 exists  but no vpn0. fw3 reload says:
>
> Warning: Section @zone[1] (lan) cannot resolve device of network 'lan'
> Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'

Not a problem, I think.

> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve device of
> network 'vpn0'
>
> tcpdump sees the ICMP request at se00 and tun0 but not at the remote target.
> this leads me to believe that it's probably a firewall problem but I don't
> know where the logs are.

logread.

> This brings me to one of the problem with had making changes in cerowrt,
> namely, how the $##$& do you debug this thing? I've had to reflash this box
> way too many times because I did something that effectively bricked it.
> right now, I would settle for knowing where to find where logs are put.

logread
dmesg

They are not written to flash or ram by default so as to never run you out
of either.

>
> thanks
> --- eric
>
>
>
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] vpn fw question

[Eric S. Johansson]

On 10/2/2014 10:02 PM, Dave Taht wrote:
> You just add the appropriate commands to /etc/config/openvpn, or so I 
> thought. 
one would think.  I'll have to try backfitting my .ovpn config into uci. 
see of that changes anything

 > logread dmesg

Thu Oct  2 21:58:59 2014 daemon.notice netifd: wan6 (12721): Command 
failed: Unknown error

not what I'm looking for but if you can give me a hint of where to start 
looking, I'll take a stab at fixing it. yes, I'm reading up on netifd. 
:-)  still haven't found an explanation for the @ge00.

Re: [Cerowrt-devel] vpn fw question

[Joel Wirāmu Pauling]

In Cerowrt the various net devices have been relabeled; as per here :
http://www.bufferbloat.net/projects/cerowrt/wiki/Device_naming_scheme


I usually add a new device via Luci  (call it somethingvpn) and select
custom device (tap0 or tun0).

Than add a new Firewall zone (VPN)

I tend to edit the /etc/config/openvpn and just point it at a custom
config (and set that entry to enabled).

Reboot and then fiddle the firewall zone forwarding mappings as appropriate.

Remember that unless you are going to be advertising routes on cerowrt
to your internet clients you will actually want to set the vpn zone as
masqueraded.


-Joel

On 3 October 2014 15:16, Eric S. Johansson <esj@eggo.org> wrote:
>
> On 10/2/2014 10:02 PM, Dave Taht wrote:
>>
>> You just add the appropriate commands to /etc/config/openvpn, or so I
>> thought.
>
> one would think.  I'll have to try backfitting my .ovpn config into uci. see
> of that changes anything
>
>> logread dmesg
>
> Thu Oct  2 21:58:59 2014 daemon.notice netifd: wan6 (12721): Command failed:
> Unknown error
>
> not what I'm looking for but if you can give me a hint of where to start
> looking, I'll take a stab at fixing it. yes, I'm reading up on netifd. :-)
> still haven't found an explanation for the @ge00.
>
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] vpn fw question

[Joel Wirāmu Pauling]

I.e Your topology looks like this :

[(Remote LAN) - VPN Client]---[INTERNET]---(Local LAN)[WAN][LAN][REMOTE-LAN])

Your Local LAN knows nothing about Remote LAN and Vice versa. There is
just a single Inteface/Client member that is a member of REMOTE-LAN.
So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
needs to be masqueraded to that Single interface.


-Joel



On 3 October 2014 14:32, Eric S. Johansson <esj@eggo.org> wrote:
> I was trying to setup my cerowrt box as an openvpn client. everything seems
> to be working. The VPN link comes up, tun0 is created. I can access machines
> on the far end of the link from the AP and vice versa. the openwrt
> incantation for the vpn says to create an interface called vpn0
>
> network.vpn0=interface
> network.vpn0.proto=none
> network.vpn0.ifname=tun0
>
> ifconfig says  tun0 exists  but no vpn0. fw3 reload says:
>
> Warning: Section @zone[1] (lan) cannot resolve device of network 'lan'
> Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'
>
> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve device of
> network 'vpn0'
>
> tcpdump sees the ICMP request at se00 and tun0 but not at the remote target.
> this leads me to believe that it's probably a firewall problem but I don't
> know where the logs are.
>
> This brings me to one of the problem with had making changes in cerowrt,
> namely, how the $##$& do you debug this thing? I've had to reflash this box
> way too many times because I did something that effectively bricked it.
> right now, I would settle for knowing where to find where logs are put.
>
> thanks
> --- eric
>
>
>
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] vpn fw question

[Joel Wirāmu Pauling]

Somewhat related question. Is anyone successfully using VxLANs in
Toronto release?

On 3 October 2014 15:24, Joel Wirāmu Pauling <joel@aenertia.net> wrote:
> I.e Your topology looks like this :
>
> [(Remote LAN) - VPN Client]---[INTERNET]---(Local LAN)[WAN][LAN][REMOTE-LAN])
>
> Your Local LAN knows nothing about Remote LAN and Vice versa. There is
> just a single Inteface/Client member that is a member of REMOTE-LAN.
> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
> needs to be masqueraded to that Single interface.
>
>
> -Joel
>
>
>
> On 3 October 2014 14:32, Eric S. Johansson <esj@eggo.org> wrote:
>> I was trying to setup my cerowrt box as an openvpn client. everything seems
>> to be working. The VPN link comes up, tun0 is created. I can access machines
>> on the far end of the link from the AP and vice versa. the openwrt
>> incantation for the vpn says to create an interface called vpn0
>>
>> network.vpn0=interface
>> network.vpn0.proto=none
>> network.vpn0.ifname=tun0
>>
>> ifconfig says  tun0 exists  but no vpn0. fw3 reload says:
>>
>> Warning: Section @zone[1] (lan) cannot resolve device of network 'lan'
>> Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'
>>
>> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve device of
>> network 'vpn0'
>>
>> tcpdump sees the ICMP request at se00 and tun0 but not at the remote target.
>> this leads me to believe that it's probably a firewall problem but I don't
>> know where the logs are.
>>
>> This brings me to one of the problem with had making changes in cerowrt,
>> namely, how the $##$& do you debug this thing? I've had to reflash this box
>> way too many times because I did something that effectively bricked it.
>> right now, I would settle for knowing where to find where logs are put.
>>
>> thanks
>> --- eric
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] vpn fw question

[Dave Taht]

On Thu, Oct 2, 2014 at 7:24 PM, Joel Wirāmu Pauling <joel@aenertia.net> wrote:
> I.e Your topology looks like this :
>
> [(Remote LAN) - VPN Client]---[INTERNET]---(Local LAN)[WAN][LAN][REMOTE-LAN])
>
> Your Local LAN knows nothing about Remote LAN and Vice versa. There is
> just a single Inteface/Client member that is a member of REMOTE-LAN.
> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
> needs to be masqueraded to that Single interface.

I'm not sure this is actually the case. What I used to do (not using openvpn
currently, took it down during heartbleed)  was push out and pull in a
route or set of routes.

'course that requires a routing protocol on the other end...

>
>
> -Joel
>
>
>
> On 3 October 2014 14:32, Eric S. Johansson <esj@eggo.org> wrote:
>> I was trying to setup my cerowrt box as an openvpn client. everything seems
>> to be working. The VPN link comes up, tun0 is created. I can access machines
>> on the far end of the link from the AP and vice versa. the openwrt
>> incantation for the vpn says to create an interface called vpn0
>>
>> network.vpn0=interface
>> network.vpn0.proto=none
>> network.vpn0.ifname=tun0
>>
>> ifconfig says  tun0 exists  but no vpn0. fw3 reload says:
>>
>> Warning: Section @zone[1] (lan) cannot resolve device of network 'lan'
>> Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'
>>
>> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve device of
>> network 'vpn0'
>>
>> tcpdump sees the ICMP request at se00 and tun0 but not at the remote target.
>> this leads me to believe that it's probably a firewall problem but I don't
>> know where the logs are.
>>
>> This brings me to one of the problem with had making changes in cerowrt,
>> namely, how the $##$& do you debug this thing? I've had to reflash this box
>> way too many times because I did something that effectively bricked it.
>> right now, I would settle for knowing where to find where logs are put.
>>
>> thanks
>> --- eric
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] vpn fw question

[Joel Wirāmu Pauling]

Yup - Routing is going to be better on performance. But is definately
the more advanced/less common use case from my experience helping
users do this.

What I've got there tends to be what most users who ask this question
are actually after.



On 3 October 2014 15:36, Dave Taht <dave.taht@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 7:24 PM, Joel Wirāmu Pauling <joel@aenertia.net> wrote:
>> I.e Your topology looks like this :
>>
>> [(Remote LAN) - VPN Client]---[INTERNET]---(Local LAN)[WAN][LAN][REMOTE-LAN])
>>
>> Your Local LAN knows nothing about Remote LAN and Vice versa. There is
>> just a single Inteface/Client member that is a member of REMOTE-LAN.
>> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
>> needs to be masqueraded to that Single interface.
>
> I'm not sure this is actually the case. What I used to do (not using openvpn
> currently, took it down during heartbleed)  was push out and pull in a
> route or set of routes.
>
> 'course that requires a routing protocol on the other end...
>
>>
>>
>> -Joel
>>
>>
>>
>> On 3 October 2014 14:32, Eric S. Johansson <esj@eggo.org> wrote:
>>> I was trying to setup my cerowrt box as an openvpn client. everything seems
>>> to be working. The VPN link comes up, tun0 is created. I can access machines
>>> on the far end of the link from the AP and vice versa. the openwrt
>>> incantation for the vpn says to create an interface called vpn0
>>>
>>> network.vpn0=interface
>>> network.vpn0.proto=none
>>> network.vpn0.ifname=tun0
>>>
>>> ifconfig says  tun0 exists  but no vpn0. fw3 reload says:
>>>
>>> Warning: Section @zone[1] (lan) cannot resolve device of network 'lan'
>>> Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'
>>>
>>> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve device of
>>> network 'vpn0'
>>>
>>> tcpdump sees the ICMP request at se00 and tun0 but not at the remote target.
>>> this leads me to believe that it's probably a firewall problem but I don't
>>> know where the logs are.
>>>
>>> This brings me to one of the problem with had making changes in cerowrt,
>>> namely, how the $##$& do you debug this thing? I've had to reflash this box
>>> way too many times because I did something that effectively bricked it.
>>> right now, I would settle for knowing where to find where logs are put.
>>>
>>> thanks
>>> --- eric
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] vpn fw question

[Joel Wirāmu Pauling]

Most of the time, they just want to access a remote VPS/Torrent
Seedbox or $service from their local network.

On 3 October 2014 15:38, Joel Wirāmu Pauling <joel@aenertia.net> wrote:
> Yup - Routing is going to be better on performance. But is definately
> the more advanced/less common use case from my experience helping
> users do this.
>
> What I've got there tends to be what most users who ask this question
> are actually after.
>
>
>
> On 3 October 2014 15:36, Dave Taht <dave.taht@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 7:24 PM, Joel Wirāmu Pauling <joel@aenertia.net> wrote:
>>> I.e Your topology looks like this :
>>>
>>> [(Remote LAN) - VPN Client]---[INTERNET]---(Local LAN)[WAN][LAN][REMOTE-LAN])
>>>
>>> Your Local LAN knows nothing about Remote LAN and Vice versa. There is
>>> just a single Inteface/Client member that is a member of REMOTE-LAN.
>>> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
>>> needs to be masqueraded to that Single interface.
>>
>> I'm not sure this is actually the case. What I used to do (not using openvpn
>> currently, took it down during heartbleed)  was push out and pull in a
>> route or set of routes.
>>
>> 'course that requires a routing protocol on the other end...
>>
>>>
>>>
>>> -Joel
>>>
>>>
>>>
>>> On 3 October 2014 14:32, Eric S. Johansson <esj@eggo.org> wrote:
>>>> I was trying to setup my cerowrt box as an openvpn client. everything seems
>>>> to be working. The VPN link comes up, tun0 is created. I can access machines
>>>> on the far end of the link from the AP and vice versa. the openwrt
>>>> incantation for the vpn says to create an interface called vpn0
>>>>
>>>> network.vpn0=interface
>>>> network.vpn0.proto=none
>>>> network.vpn0.ifname=tun0
>>>>
>>>> ifconfig says  tun0 exists  but no vpn0. fw3 reload says:
>>>>
>>>> Warning: Section @zone[1] (lan) cannot resolve device of network 'lan'
>>>> Warning: Section @zone[2] (guest) cannot resolve device of network 'guest'
>>>>
>>>> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve device of
>>>> network 'vpn0'
>>>>
>>>> tcpdump sees the ICMP request at se00 and tun0 but not at the remote target.
>>>> this leads me to believe that it's probably a firewall problem but I don't
>>>> know where the logs are.
>>>>
>>>> This brings me to one of the problem with had making changes in cerowrt,
>>>> namely, how the $##$& do you debug this thing? I've had to reflash this box
>>>> way too many times because I did something that effectively bricked it.
>>>> right now, I would settle for knowing where to find where logs are put.
>>>>
>>>> thanks
>>>> --- eric
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>>
>> https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] vpn fw question

[Eric S. Johansson]

On 10/2/2014 10:24 PM, Joel Wirāmu Pauling wrote:
> I.e Your topology looks like this :
>
> [(Remote LAN) - VPN Client]---[INTERNET]---(Local LAN)[WAN][LAN][REMOTE-LAN])
>
> Your Local LAN knows nothing about Remote LAN and Vice versa. There is
> just a single Inteface/Client member that is a member of REMOTE-LAN.
> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
> needs to be masqueraded to that Single interface.

ah, thanks for the clarification.  my function oriented topology looks 
like this:

[ 34-38 target lan - vpn server - fw ] - - - [ I ] - + -( fw - vpn 
client - - - lan - - - workerbees(6) )
+ -( rw worker bee )
+ -( rw worker bee )
+ -( cerowrt worker bee ) ...

I don't think the natted form is going to work terribly well because all 
the WB's need access to all the target machines. Also our routing tables 
are… significant

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt 
Iface
0.0.0.0         73.38.246.1     0.0.0.0         UG        0 0          0 
ge00
10.42.66.0      10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.1.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.2.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.3.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.4.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.5.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.6.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.7.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.8.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.9.0       10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.10.0      10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.11.0      10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.12.0      10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.13.0      10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.14.0      10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.43.15.0      10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.199.188.0    10.199.188.193  255.255.255.0   UG        0 0          0 
tun0
10.199.188.193  0.0.0.0         255.255.255.255 UH        0 0          0 
tun0
73.38.246.0     0.0.0.0         255.255.254.0   U         0 0          0 
ge00
172.30.42.0     0.0.0.0         255.255.255.224 U         0 0          0 
se00
172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *
172.30.42.64    0.0.0.0         255.255.255.224 U         0 0          0 
sw00
172.30.42.96    0.0.0.0         255.255.255.224 U         0 0          0 
sw10
192.168.9.0     10.199.188.193  255.255.255.0   UG        0 0          0 
tun0

and WTH is this?
172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *

--- eric

Re: [Cerowrt-devel] vpn fw question

[Dave Taht]

On Thu, Oct 2, 2014 at 8:05 PM, Eric S. Johansson <esj@eggo.org> wrote:
>
> On 10/2/2014 10:24 PM, Joel Wirāmu Pauling wrote:
>>
>> I.e Your topology looks like this :
>>
>> [(Remote LAN) - VPN Client]---[INTERNET]---(Local
>> LAN)[WAN][LAN][REMOTE-LAN])
>>
>> Your Local LAN knows nothing about Remote LAN and Vice versa. There is
>> just a single Inteface/Client member that is a member of REMOTE-LAN.
>> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
>> needs to be masqueraded to that Single interface.
>
>
> ah, thanks for the clarification.  my function oriented topology looks like
> this:
>
> [ 34-38 target lan - vpn server - fw ] - - - [ I ] - + -( fw - vpn client -
> - - lan - - - workerbees(6) )
> + -( rw worker bee )
> + -( rw worker bee )
> + -( cerowrt worker bee ) ...
>
> I don't think the natted form is going to work terribly well because all the
> WB's need access to all the target machines. Also our routing tables are…
> significant

Personally I find the output of

ip route show

to be much more readable and usable nowadays.

> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 0.0.0.0         73.38.246.1     0.0.0.0         UG        0 0          0
> ge00
> 10.42.66.0      10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.1.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.2.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.3.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.4.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.5.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.6.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.7.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.8.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.9.0       10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.10.0      10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.11.0      10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.12.0      10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.13.0      10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.14.0      10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.43.15.0      10.199.188.193  255.255.255.0   UG        0 0          0
> tun0

Ideally you should be able to shrink that 10.43 network into a single
10.43.0.0/20 route.

> 10.199.188.0    10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
> 10.199.188.193  0.0.0.0         255.255.255.255 UH        0 0          0
> tun0
> 73.38.246.0     0.0.0.0         255.255.254.0   U         0 0          0
> ge00
> 172.30.42.0     0.0.0.0         255.255.255.224 U         0 0          0
> se00
> 172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *
> 172.30.42.64    0.0.0.0         255.255.255.224 U         0 0          0
> sw00
> 172.30.42.96    0.0.0.0         255.255.255.224 U         0 0          0
> sw10
> 192.168.9.0     10.199.188.193  255.255.255.0   UG        0 0          0
> tun0
>
> and WTH is this?
> 172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *

That is what is called a "covering route". The interfaces in cerowrt are
all /27s out of a single /24. Just as you could just do a 10.43.0.0/20 route
instead of the 16 10.43 routes above.

So we export via babel that single /24 by creating an "unreachable" route
for it, which is visible externally to the router, and internally to the router
we have the /27s that override the /24, that are not visible outside the
router.

Clear as mud, right?

Here is part of my route table. Old Cerowrt used to export 9 routes
visible to other routers..

172.21.0.0/27 dev ge00  proto kernel  scope link  src 172.21.0.18
172.21.0.64/27 via 172.21.0.1 dev ge00  proto babel onlink
172.21.0.96/27 via 172.21.0.1 dev ge00  proto babel onlink
172.21.0.128/27 via 172.21.0.1 dev ge00  proto babel onlink
... add the host gateway and the other 4 interfaces...

Toronto exports 1 (or 2) depending on the alternate paths available

The s+ and gw+ devices

172.21.18.0/24 via 172.21.0.7 dev ge00  proto babel onlink

The ge00 device is on another network, covered in this route

172.21.3.0/24 via 172.21.0.7 dev ge00  proto babel onlink


less exported routes = smaller routing packets, smaller routing
tables, faster routing updates, less route lookups while transferring
data, and better use of the distance->vector mechanisms, and so on.

In terms of scaling factors this makes it feasible to route together
at least 700 boxes without
too much fear of overwhelming anything. (But I haven't got around to
resimulating the results,
like so many other things - and the limit at least used to be some
inefficient code in babeld,
not any inherent limit to the protocol)

>
> --- eric
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] vpn fw question

[Dave Taht]

hmm. bcp38 postdates the last work I tried with openvpn.

In your case you will want to either add to /etc/config/bcp38

        list nomatch '10.43.0.0/20'
        list nomatch '10.42.66.0/24'
        list nomatch '10.199.188.0/24'

or (better) insert and remove them from the ipset list dynamically
when the vpn starts/stops.

Or kill bcp38 entirely for a while while you debug.

On Thu, Oct 2, 2014 at 8:38 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Thu, Oct 2, 2014 at 8:05 PM, Eric S. Johansson <esj@eggo.org> wrote:
>>
>> On 10/2/2014 10:24 PM, Joel Wirāmu Pauling wrote:
>>>
>>> I.e Your topology looks like this :
>>>
>>> [(Remote LAN) - VPN Client]---[INTERNET]---(Local
>>> LAN)[WAN][LAN][REMOTE-LAN])
>>>
>>> Your Local LAN knows nothing about Remote LAN and Vice versa. There is
>>> just a single Inteface/Client member that is a member of REMOTE-LAN.
>>> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic
>>> needs to be masqueraded to that Single interface.
>>
>>
>> ah, thanks for the clarification.  my function oriented topology looks like
>> this:
>>
>> [ 34-38 target lan - vpn server - fw ] - - - [ I ] - + -( fw - vpn client -
>> - - lan - - - workerbees(6) )
>> + -( rw worker bee )
>> + -( rw worker bee )
>> + -( cerowrt worker bee ) ...
>>
>> I don't think the natted form is going to work terribly well because all the
>> WB's need access to all the target machines. Also our routing tables are…
>> significant
>
> Personally I find the output of
>
> ip route show
>
> to be much more readable and usable nowadays.
>
>> Kernel IP routing table
>> Destination     Gateway         Genmask         Flags   MSS Window  irtt
>> Iface
>> 0.0.0.0         73.38.246.1     0.0.0.0         UG        0 0          0
>> ge00
>> 10.42.66.0      10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.1.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.2.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.3.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.4.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.5.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.6.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.7.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.8.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.9.0       10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.10.0      10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.11.0      10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.12.0      10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.13.0      10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.14.0      10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.43.15.0      10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>
> Ideally you should be able to shrink that 10.43 network into a single
> 10.43.0.0/20 route.
>
>> 10.199.188.0    10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>> 10.199.188.193  0.0.0.0         255.255.255.255 UH        0 0          0
>> tun0
>> 73.38.246.0     0.0.0.0         255.255.254.0   U         0 0          0
>> ge00
>> 172.30.42.0     0.0.0.0         255.255.255.224 U         0 0          0
>> se00
>> 172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *
>> 172.30.42.64    0.0.0.0         255.255.255.224 U         0 0          0
>> sw00
>> 172.30.42.96    0.0.0.0         255.255.255.224 U         0 0          0
>> sw10
>> 192.168.9.0     10.199.188.193  255.255.255.0   UG        0 0          0
>> tun0
>>
>> and WTH is this?
>> 172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *
>
> That is what is called a "covering route". The interfaces in cerowrt are
> all /27s out of a single /24. Just as you could just do a 10.43.0.0/20 route
> instead of the 16 10.43 routes above.
>
> So we export via babel that single /24 by creating an "unreachable" route
> for it, which is visible externally to the router, and internally to the router
> we have the /27s that override the /24, that are not visible outside the
> router.
>
> Clear as mud, right?
>
> Here is part of my route table. Old Cerowrt used to export 9 routes
> visible to other routers..
>
> 172.21.0.0/27 dev ge00  proto kernel  scope link  src 172.21.0.18
> 172.21.0.64/27 via 172.21.0.1 dev ge00  proto babel onlink
> 172.21.0.96/27 via 172.21.0.1 dev ge00  proto babel onlink
> 172.21.0.128/27 via 172.21.0.1 dev ge00  proto babel onlink
> ... add the host gateway and the other 4 interfaces...
>
> Toronto exports 1 (or 2) depending on the alternate paths available
>
> The s+ and gw+ devices
>
> 172.21.18.0/24 via 172.21.0.7 dev ge00  proto babel onlink
>
> The ge00 device is on another network, covered in this route
>
> 172.21.3.0/24 via 172.21.0.7 dev ge00  proto babel onlink
>
>
> less exported routes = smaller routing packets, smaller routing
> tables, faster routing updates, less route lookups while transferring
> data, and better use of the distance->vector mechanisms, and so on.
>
> In terms of scaling factors this makes it feasible to route together
> at least 700 boxes without
> too much fear of overwhelming anything. (But I haven't got around to
> resimulating the results,
> like so many other things - and the limit at least used to be some
> inefficient code in babeld,
> not any inherent limit to the protocol)
>
>>
>> --- eric
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> https://www.bufferbloat.net/projects/make-wifi-fast



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] vpn fw question

[Eric S. Johansson]

On 10/2/2014 11:38 PM, Dave Taht wrote:
> Personally I find the output of
>
> ip route show
>
> to be much more readable and usable nowadays.

you are quite right. It is. thank you for the reminder to kill off old 
habits and build a new old habit.

 > Ideally you should be able to shrink that 10.43 network into a single 
10.43.0.0/20 route.

that is my plan when I replace the firewall in the main office. There is 
a lot of Cruft in the old firewall including multiple holes for things 
people "used to do" but they don't dare close them because they might 
have to do them again. I wish IP cop was sufficiently sophisticated for 
this purpose but I think the UI gotten rather crufty since I last worked 
on it.

You see, I work in the land of myth and magic. A little bit of Hollywood 
right here in Boston.

and WTH is this?
172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *

> That is what is called a "covering route". The interfaces in cerowrt are
> all /27s out of a single /24. Just as you could just do a 10.43.0.0/20 route
> instead of the 16 10.43 routes above.

I've got to learn Lua and how to debug in this environment better. I 
should probably explain. I was one of the founding members of the IPCop 
firewall. We put a lot of energy into making it simple and easy to use 
so that it was harder to make mistakes. I apologize in advance if I 
offend anyone but the current UI for Cerowrt/openwrt is not shaped by 
workflow but by the need to expose everything.

I'm hoping that I will be able to demonstrate what I mean by an error 
resistant UI sometime over the next few months. In the meantime however, 
I'm going to try and learn enough so I can be useful fixing small bugs 
and reducing chaos enhancers in tools like uci.

And I just saw your other mail about BCP 38. What is it?

--- eric

Re: [Cerowrt-devel] vpn fw question

[Dave Taht]

If for example, you can coax openvpn to name it's tunnel device se01,
the existing firewall rules using the s+ pattern match will
automagically pick it up.

I've kind of wanted the same feature for vlans but never figured out
how to turn a
se00.2 into a gw02.

On Thu, Oct 2, 2014 at 9:12 PM, Eric S. Johansson <esj@eggo.org> wrote:
>
> On 10/2/2014 11:38 PM, Dave Taht wrote:
>>
>> Personally I find the output of
>>
>> ip route show
>>
>> to be much more readable and usable nowadays.
>
>
> you are quite right. It is. thank you for the reminder to kill off old
> habits and build a new old habit.

best way to look at ipv6, also.

>
>> Ideally you should be able to shrink that 10.43 network into a single
>> 10.43.0.0/20 route.
>
> that is my plan when I replace the firewall in the main office. There is a
> lot of Cruft in the old firewall including multiple holes for things people
> "used to do" but they don't dare close them because they might have to do
> them again. I wish IP cop was sufficiently sophisticated for this purpose
> but I think the UI gotten rather crufty since I last worked on it.
>
> You see, I work in the land of myth and magic. A little bit of Hollywood
> right here in Boston.
>
> and WTH is this?
> 172.30.42.0     0.0.0.0         255.255.255.0   !         0 0          0 *
>
>> That is what is called a "covering route". The interfaces in cerowrt are
>> all /27s out of a single /24. Just as you could just do a 10.43.0.0/20
>> route
>> instead of the 16 10.43 routes above.
>
>
> I've got to learn Lua and how to debug in this environment better. I should
> probably explain.

It is generally simplest to run a x86 vm of openwrt.

> I was one of the founding members of the IPCop firewall.

Very cool!

> We put a lot of energy into making it simple and easy to use so that it was
> harder to make mistakes. I apologize in advance if I offend anyone but the
> current UI for Cerowrt/openwrt is not shaped by workflow but by the need to
> expose everything.

Oh no. A lot of the complexity in cerowrt is just there to make sure
that complex
setups can work. I care a lot about exposing appropriate functionality, routing
in an IoT world, as one example, not one whit about the gui stuff.

The luci part of openwrt is sorely in need of more bodies.

There is an attempt to rewrite the gui in more javascript in luci2.

the openwireless.org folk are doing their own gui for cero, and realizing that
the 80/20 rule applies, but it's a different 20 for every user. See their
mailing list and codebase for details.

Every manufacturer dumbs down the gui so much these days that it's
impossible to turn nat off on current netgear, dd-link, and apple products.

I, personally, happen to really like naming interfaces after their function
given the expressiveness of the pattern matching syntax, but it is
an idea few have adopted....

> I'm hoping that I will be able to demonstrate what I mean by an error
> resistant UI sometime over the next few months. In the meantime however, I'm
> going to try and learn enough so I can be useful fixing small bugs and
> reducing chaos enhancers in tools like uci.

The successor to BB is called chaos calmer.

I suggest joining the relevant #openwrt-devel and #bufferbloat channels.

>
> And I just saw your other mail about BCP 38. What is it?

The answer to dns amplification attacks in particular.

http://tools.ietf.org/html/bcp38

https://www.youtube.com/watch?v=9-StM3Zfv6o&feature=youtu.be&list=PLSnVjSuzLJcxbiilGE421Zx7Wk3Wez8NS
>
> --- eric
>
>



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Cerowrt-devel] vpn fw question

[Eric S. Johansson]

On 10/3/2014 12:32 AM, Dave Taht wrote:

> Oh no. A lot of the complexity in cerowrt is just there to make sure
> that complex
> setups can work. I care a lot about exposing appropriate functionality, routing
> in an IoT world, as one example, not one whit about the gui stuff.

I agree that complexity should be exposed to some level but it shouldn't 
be your first option. I have this overly told tale about my sender pays 
anti-spam system call two Penny blue. It worked well and where showed it 
off at the MIT antispam conference, there were a significant number of 
folks that want to steal my user interface they liked it so much. It 
changed the whole paradigm of antispam interfaces. The entire focus was 
on getting the job done without making's fighting spam your life. I want 
to carry the philosophy through for firewalls.  I'm almost willing to 
bet you were really expensive lunch that I can give you the same control 
you want in a much more understandable package. :-)

The reality today is most IT folks don't have time to be security 
experts. Like in what I'm trying to do with VPNs, my intent is to bridge 
networks between multiple offices. Did this with IP cop and each node  
took approximately 45 minutes to get running with IP sec. The secret is 
following the intent of what the person wants to do so they get the job 
done get on with their life.

For example, I would love to build an interface that based on a 
graphical representation of the network. By drawing lines you show 
logical connectivity between two nodes. Tapping on each end of the line 
brings up the dialogue to show the characteristics of that link such as 
a pinhole for the service. There's other ways of presenting more 
detailed information that one can use to quickly make the right change.



>
> The luci part of openwrt is sorely in need of more bodies.
Yeah that's the challenge for me. I've got a broken body. My hands don't 
work so good and I use speech recognition which means any time I do a 
lot of work in some area, I build a speech user interface to do what's 
necessary to save my hands. If you think regular GUIs are hard, try 
writing a speech user interface. Too many people think in terms of how 
to do it rather than what you want to do.
>
> There is an attempt to rewrite the gui in more javascript in luci2.
In many ways that's a wise choice as long as you don't use JavaScript ;-)
>
> the openwireless.org folk are doing their own gui for cero, and realizing that
> the 80/20 rule applies, but it's a different 20 for every user. See their
> mailing list and codebase for details.
That's a good point and that's why you always want to have a backup 
interface that exposes everything. But that's also why I'm a good user 
interface designer. If I listened to enough use cases, I can come up 
with a more general interface you might think possible at first glance. 
I also am a bit of a cynic which manifests as "the only truly intuitive 
user interface is the mammalian nipple and as any nursing mom will tell 
you, even that isn't intuitive enough for a significant number of users"
>
> Every manufacturer dumbs down the gui so much these days that it's
> impossible to turn nat off on current netgear, dd-link, and apple products.

Yeah that's  part of the  problem. People think reducing functionality 
is a  simpler  interface. It's just a different kind of complexity. that 
is a rant I will save some bar evening over root beer.
>
> I, personally, happen to really like naming interfaces after their function
> given the expressiveness of the pattern matching syntax, but it is
> an idea few have adopted....

I'm with you. So why not do it? Convention is only useful if it serves a 
purpose. At the same time, with the relationship structure between all 
the different elements because there may be other simplifications that 
can come out of a different kind of complexity. For example, in UCI you 
have the IP address and network information scattered through multiple 
files and any time the solution to a problem with changing networks is 
sed, you have the wrong solution. I'm hoping to extend UCI to work with 
named constants instead of literals for arguments. A little bit more 
complexity in the right place, simplifies configuration files and 
configurability.

This change also makes it possible to start calculating the relationship 
between the different subnets so that if you need to make the network 
subnet bigger, you change subnet mask and everything else falls out 
automatically.  I'm big on making things self adjusting like that 
because it makes my hands not hurt. If I need a more professional 
explanation I say it's a form of universal design to accommodate all 
abilities. :-)

Anyway, I need to get to bed so I can get some good work in tomorrow. 
Joys of being a self-employed crip.

--- eric