2017-05-23 - Re: [GRASE-Hotspot] Why I am getting martian source package mesages from syslog

Header Data

From: Timothy White <ti***8@gmail.com>
Message Hash: 9dc04acb4ff2d263953f4cc75c603ca0cee656f48584293c7bcbb791560d16ad
Message ID: <CAESLx0KdCnxrvBy3+tRPStq1PjA-QR2RAmrCia-aL8LPzFRvjw@mail.gmail.com>
Reply To: <CAPYsbFaL75DVYd4VbbHkwqFJ8==PX-rUXKMkpa3vp5xaRopU3g@mail.gmail.com>
UTC Datetime: 2017-05-23 03:28:50 UTC
Raw Date: Tue, 23 May 2017 20:28:50 +1000

Raw message 

On Fri, May 19, 2017 at 12:41 PM, Tubeta Taenang <tu***g@gmail.com>
wrote:

>
> Here is my setup:
>
> WAN side ome through MODEM - MANAGED SWITCH - ROUTER 1
> (111.92.179.46/29) <--> LAN (192.168.x.x/24)
>
>                                      MODEM - MANAGED SWITCH - GRASE
> BOX (111.92.179.45) <--> LAN (10.1.x.x/24) ETH0 is facing the Internet
> side while ETH1 ( with tun0 and tun1) is where grase resides.
>
>
Something isn't adding up.

According to your IP ranges,  you have 8 IP's in your WAN? Is your Modem
also a router? In which case, you have "multiple" routers, because you have
ROUTER 1, which is a router for your LAN, and you have the Grase server
acting as a router for the wifi?

Side note, I probably should update the install docs, but Grase was never
designed to be on a public IP without some sort of firewall being setup.
You probably want to lock down your eth0 on the Grase server.

So looking at your setup, and the martian log's, it appears that 10.1.0.52
(a hotspot client) is sending packets with an origination IP
of 104.116.243.17. In other words, it's "routing" packets the wrong way. So
find out what that client is, and you'll be on track to working out the
issue.

Lastly, you have a few oddities setup.
uamallowed=10.1.0.2
uamallowed=10.1.0.31
uamallowed=10.1.0.32
uamallowed=10.1.0.33
uamallowed=10.1.0.34
uamallowed=10.1.0.35
uamallowed=10.1.0.36
uamallowed=10.1.0.39

Basically, you're telling the hotspot to allow access to those IP's, except
all of those IP's are on the Hotspot side of the network, so direct client
to client communication will work for them, and those rules will do nothing.

        #adding routing to network 10.1.0.0 attached to dev tun0
        up route add -net 10.1.0.0/24  gw 10.1.0.1 dev tun0
        #add route to network 10.5.0.0 via dev tun0
        up route add -net 10.5.0.0/24 gw 10.1.0.1 dev tun0

Why do you have these? The 10.1.0.0/24 network will be directly attached to
tun0 or tun1 (depending on what order things come up), and so won't need
that route. And 10.5.0.0/24, you're telling it to route through CoovaChilli
as well, except it's not going to have that network attached, and if it
did, it would be a directly attached network not needing a router.

You shouldn't need to be modifying any routes in 'up' scripts,
Ubuntu/Debian does a good job of handling that itself, and if you are doing
fancy routing, it won't be to gw 101.0.1 on tun0.

Regards

Tim

Thread