* [Cerowrt-devel] vpn fw question @ 2014-10-03 1:32 Eric S. Johansson 2014-10-03 2:02 ` Dave Taht 2014-10-03 2:24 ` Joel Wirāmu Pauling 0 siblings, 2 replies; 15+ messages in thread From: Eric S. Johansson @ 2014-10-03 1:32 UTC (permalink / raw) To: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 1:32 [Cerowrt-devel] vpn fw question Eric S. Johansson @ 2014-10-03 2:02 ` Dave Taht 2014-10-03 2:16 ` Eric S. Johansson 2014-10-03 2:24 ` Joel Wirāmu Pauling 1 sibling, 1 reply; 15+ messages in thread From: Dave Taht @ 2014-10-03 2:02 UTC (permalink / raw) To: Eric S. Johansson; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 2:02 ` Dave Taht @ 2014-10-03 2:16 ` Eric S. Johansson 2014-10-03 2:21 ` Joel Wirāmu Pauling 0 siblings, 1 reply; 15+ messages in thread From: Eric S. Johansson @ 2014-10-03 2:16 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 2:16 ` Eric S. Johansson @ 2014-10-03 2:21 ` Joel Wirāmu Pauling 0 siblings, 0 replies; 15+ messages in thread From: Joel Wirāmu Pauling @ 2014-10-03 2:21 UTC (permalink / raw) To: Eric S. Johansson; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 1:32 [Cerowrt-devel] vpn fw question Eric S. Johansson 2014-10-03 2:02 ` Dave Taht @ 2014-10-03 2:24 ` Joel Wirāmu Pauling 2014-10-03 2:33 ` Joel Wirāmu Pauling ` (2 more replies) 1 sibling, 3 replies; 15+ messages in thread From: Joel Wirāmu Pauling @ 2014-10-03 2:24 UTC (permalink / raw) To: Eric S. Johansson; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 2:24 ` Joel Wirāmu Pauling @ 2014-10-03 2:33 ` Joel Wirāmu Pauling 2014-10-03 2:36 ` Dave Taht 2014-10-03 3:05 ` Eric S. Johansson 2 siblings, 0 replies; 15+ messages in thread From: Joel Wirāmu Pauling @ 2014-10-03 2:33 UTC (permalink / raw) To: Eric S. Johansson; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 2:24 ` Joel Wirāmu Pauling 2014-10-03 2:33 ` Joel Wirāmu Pauling @ 2014-10-03 2:36 ` Dave Taht 2014-10-03 2:38 ` Joel Wirāmu Pauling 2014-10-03 3:05 ` Eric S. Johansson 2 siblings, 1 reply; 15+ messages in thread From: Dave Taht @ 2014-10-03 2:36 UTC (permalink / raw) To: Joel Wirāmu Pauling; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 2:36 ` Dave Taht @ 2014-10-03 2:38 ` Joel Wirāmu Pauling 2014-10-03 2:41 ` Joel Wirāmu Pauling 0 siblings, 1 reply; 15+ messages in thread From: Joel Wirāmu Pauling @ 2014-10-03 2:38 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 2:38 ` Joel Wirāmu Pauling @ 2014-10-03 2:41 ` Joel Wirāmu Pauling 0 siblings, 0 replies; 15+ messages in thread From: Joel Wirāmu Pauling @ 2014-10-03 2:41 UTC (permalink / raw) To: Dave Taht; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 2:24 ` Joel Wirāmu Pauling 2014-10-03 2:33 ` Joel Wirāmu Pauling 2014-10-03 2:36 ` Dave Taht @ 2014-10-03 3:05 ` Eric S. Johansson 2014-10-03 3:38 ` Dave Taht 2 siblings, 1 reply; 15+ messages in thread From: Eric S. Johansson @ 2014-10-03 3:05 UTC (permalink / raw) To: Joel Wirāmu Pauling; +Cc: cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 3:05 ` Eric S. Johansson @ 2014-10-03 3:38 ` Dave Taht 2014-10-03 4:09 ` Dave Taht 2014-10-03 4:12 ` Eric S. Johansson 0 siblings, 2 replies; 15+ messages in thread From: Dave Taht @ 2014-10-03 3:38 UTC (permalink / raw) To: Eric S. Johansson; +Cc: Joel Wirāmu Pauling, cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 3:38 ` Dave Taht @ 2014-10-03 4:09 ` Dave Taht 2014-10-03 4:12 ` Eric S. Johansson 1 sibling, 0 replies; 15+ messages in thread From: Dave Taht @ 2014-10-03 4:09 UTC (permalink / raw) To: Eric S. Johansson; +Cc: Joel Wirāmu Pauling, cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 3:38 ` Dave Taht 2014-10-03 4:09 ` Dave Taht @ 2014-10-03 4:12 ` Eric S. Johansson 2014-10-03 4:32 ` Dave Taht 1 sibling, 1 reply; 15+ messages in thread From: Eric S. Johansson @ 2014-10-03 4:12 UTC (permalink / raw) To: Dave Taht; +Cc: Joel Wirāmu Pauling, cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 4:12 ` Eric S. Johansson @ 2014-10-03 4:32 ` Dave Taht 2014-10-03 5:38 ` Eric S. Johansson 0 siblings, 1 reply; 15+ messages in thread From: Dave Taht @ 2014-10-03 4:32 UTC (permalink / raw) To: Eric S. Johansson; +Cc: Joel Wirāmu Pauling, cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cerowrt-devel] vpn fw question 2014-10-03 4:32 ` Dave Taht @ 2014-10-03 5:38 ` Eric S. Johansson 0 siblings, 0 replies; 15+ messages in thread From: Eric S. Johansson @ 2014-10-03 5:38 UTC (permalink / raw) To: Dave Taht; +Cc: Joel Wirāmu Pauling, cerowrt-devel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-10-03 5:38 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-03 1:32 [Cerowrt-devel] vpn fw question Eric S. Johansson 2014-10-03 2:02 ` Dave Taht 2014-10-03 2:16 ` Eric S. Johansson 2014-10-03 2:21 ` Joel Wirāmu Pauling 2014-10-03 2:24 ` Joel Wirāmu Pauling 2014-10-03 2:33 ` Joel Wirāmu Pauling 2014-10-03 2:36 ` Dave Taht 2014-10-03 2:38 ` Joel Wirāmu Pauling 2014-10-03 2:41 ` Joel Wirāmu Pauling 2014-10-03 3:05 ` Eric S. Johansson 2014-10-03 3:38 ` Dave Taht 2014-10-03 4:09 ` Dave Taht 2014-10-03 4:12 ` Eric S. Johansson 2014-10-03 4:32 ` Dave Taht 2014-10-03 5:38 ` Eric S. Johansson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox