'Puter is up at CS.is/test but wifi is isp ip addresses

[FoodMaven]

Viewing ipleak.net, the CSVPN is up and no leaks. But the wifi isn't. Pardon. I've no idea whether I'm running as a "client". I see there is no bridge mode as client in OpenWRT/LuCI. I see How-Tos to bridge the ethernet to wifi, but have no idea which ethernet/wifi.

[parityboy]

@OP

Yes, you are running OpenVPN as a client on your router. When you connect a device via WiFi, what internal IP address is handed to the device, i.e. 192.168.x.x? How does it compare to the internal IP address handed to a device connected via Ethernet?

Could you post them? Thanks.

[FoodMaven]

'puter's ip: 192.168.1.185
wifi device ip: 192.168.1.109

[parityboy]

@OP

I don't physically have one of these routers so I can't actually test it, but it looks like the Ethernet and the WiFi interfaces are already bridged together, which is why devices connected to either are given an IP address in the 192.168.1.x range.

Can you post the routing table for your router? The output should look something like (but not exactly like, especially in the GUI) this:

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router.stagelef 0.0.0.0         UG    100    0        0 enp6s0
link-local      *               255.255.0.0     U     1000   0        0 enp6s0
192.168.2.0     *               255.255.255.0   U     100    0        0 enp6s0
192.168.3.0     *               255.255.255.0   U     0      0        0 vboxnet0
192.168.4.0     *               255.255.255.0   U     0      0        0 vboxnet1
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0


Cheers.

[FoodMaven]

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.33.0.1       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 eth0.2
10.33.0.0       0.0.0.0         255.255.0.0     U     0      0        0 tun0
104.238.195.140 192.168.1.254   255.255.255.255 UGH   0      0        0 eth0.2
128.0.0.0       10.33.0.1       128.0.0.0       UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0.2
192.168.1.254   0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

[parityboy]

@OP

OK, thank you for that.

From what I can see, br-lan is the bridge between Wi-Fi and Ethernet and is used by your router to send/receive traffic across your LAN - it's also why both Ethernet and WiFi clients receive IP addresses in the same subnet range. 104.238.195.140 is the IP address of the exit node your router is connected to.

tun0 is the "fake network interface" for your end of the VPN tunnel. Logically, tun0 is stacked "above" eth0.2 so that traffic flows "downwards" through tun0 and then eth0.2 - I'm assuming that eth0.2 is the WAN interface of your router.

Could you clarify what 192.168.1.254 belongs to? I'm assuming it's an ISP-provided router sitting in front of your OpenWRT router, but could you clarify?

Cheers.

[FoodMaven]

192.168.1.254 is the IP address of the ISP. It is the device (modem, router, wifi) through which I have Internet access.

[parityboy]

192.168.1.254 is the IP address of the ISP. It is the device (modem, router, wifi) through which I have Internet access.

So this is a separate device from your OpenWRT router, yes? Could it be that you have connected to its WiFi in error, rather than the OpenWRT router's WiFi? (I have to ask).

[FoodMaven]

Yes, separate device.

The ISP supplied device is a modem-router-wifi unit. Only one ethernet cable runs from it's LAN port to the OpenWRT's WAN port. Only one cable from the OpenWRT device LAN port runs to an unmanaged switch. All connected devices (computer, Raspberry PI, DVD player) obtain 'net access through the switch.

The tablet, laptop and phone connect via wifi.

To access the admin page of the modem, I have to move a cable from the ISP modem's WAN port to it's LAN port. But then, obviously I have no 'net access but I am able to control (turn on or off) various modem config settings.

[parityboy]

@OP

OK, I understand that you have two router devices, but do both of them have WiFi, or only one? If it's only one, is it the ISP-provided device? If it's both, are you absolutely sure you're connecting to the OpenWRT device one via WiFi?

[FoodMaven]

Currently, due to tech problems I've not resolved, the modem device (with wifi) has an SSID of: Xx@x7qDD or like that. The OpenWRT/OpenVPN/Cryptostorm device has an SSID of a (pronouncable) noun. Both devices' wifi are working. I'll be shutting the modem's wifi off this week. I am absolutely certain that the wifi devices I have connected to the proper noun device are OpenWRT/OpenVPN/CS. But the wifi devices (Android phone, tablet) don't show at cryptostorm.is/test in green. They say "not connected".

[parityboy]

@FoodMaven

I think I've found the issue.

Code: Select all

Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
167.109.167.107.in-addr.arpa    name = a29-02-09.opera-mini.net.

Authoritative answers can be found from:



opera-mini.net is a proxy service used by the Opera Mini browser, I imagine to deliver web pages more quickly over the network. I can only assume that the proxy service uses caching, compression and other data reduction techniques to provide a faster experience.

The browser connects to the proxy service while using CS as a transport layer, in other words "on top of" the VPN connection in the logical sense, in the same way that the VPN connection operates "on top of" your naked connection.

Because of this, the IP address that the Cryptostorm website sees is the address of the proxy service, since that is the last address your traffic leaves before hitting the Cryptostorm website.

If you wish to test this out, install Firefox or Dolphin on your mobile device and run the test again. You should get a positive result.

To access the admin page of the modem, I have to move a cable from the ISP modem's WAN port to it's LAN port. But then, obviously I have no 'net access but I am able to control (turn on or off) various modem config settings.

Can you clarify this? With your current setup - where the ISP device is logically sitting "in front" of your OpenWRT router, you should be able to access the ISP device's admin console from any device connected to your OpenWRT router - the router should be able to route traffic to the ISP device, since it has a route to it. (judging by the routing table).

[FoodMaven]

Discarding Opera/Mini solved the green/red problem. I'm on the CS "darknet". I don't think of this as "dark" I see it as the light at the end of the tunnel. But that's haberdashery. Sorry.

All ISP provided wifi is off. The problem is entirely with Opera and other non-secure browsers wanting to give away location info, per the above post. Once I started with Firefox, I had no more RTC problems at ipleak.net

The modem's ethernet ports has an ethernet cable attached to it (yellow ports). That cables other end plugs into an unmanaged switch. The ports from the switch connect to all cabled devices: computer, printer, other computer, TV, raspberry pi, dvd. I'm thinking of trying the cabling thusly:

from the modem's ethernet (yellow) port via cable to the Cryptostorm activated devices WAN (blue) port. From the Cryptostorm activated router's LAN (yellow) to the ethernet switch for the remainder of the devices.

[parityboy]

Discarding Opera/Mini solved the green/red problem. I'm on the CS "darknet". I don't think of this as "dark" I see it as the light at the end of the tunnel. But that's haberdashery. Sorry.

I see what you did there. But yes, by providing a transparent connection to Tor and I2P, it serves as a path to a much freer Internet.

I'm thinking of trying the cabling thusly:

from the modem's ethernet (yellow) port via cable to the Cryptostorm activated devices WAN (blue) port. From the Cryptostorm activated router's LAN (yellow) to the ethernet switch for the remainder of the devices.

This is precisely how I thought you would connect it. You should still be able to ping the ISP device, if not you may have to change the LAN setting on either the ISP device or the OpenWRT to give it a different subnet range, i.e. 192.168.2.x.

[FoodMaven]

Sadly, this whole project may come to naught. The Sports App, on seeing the exit node, says: cannot establish a session:

geo-location-unreliable

So the purpose of having CS now seems in vain. I am not quitting CS. For the tiny price, I never would. My computer is still tunneling. So some devices are safer.

I wrote the support group at the app and told them that I was willing to help them know the location, but I'm certain that they were gathering much more info than that and they'll never stop as there is tracking/$ involved.

[parityboy]

@FoodMaven

Is the exit node based in the U.S. (or wherever the sports app is expecting it)?

[FoodMaven]

Yes, the current exit node is:

cstorm_linux-uswest_udp.ovpn

[dh45]

dear @Foodmaven

I'm just as curios to know the name of the Sports App in-mention.

Care to share with us?

I might be using the same app etc .. and i guess the reason for the block on their end is more than mere geo-restrictions. Maybe they have reasons for blocking known VPN ranges altogether. Like maybe combatting fraud by end users who I presume have to subscribe or recruit members as part of normal app usage.

They intend to avoid fraud sign-ups which is fine, but blocking entirely is .. absurd.


thnx!