1

I have followed the official Raspberry Pi documentation's guide to setting up my Raspberry Pi as a wireless access point, with a shared internet connection using the bridge functionality discussed at the end of the guide. This is working perfectly, and I can utilise the access point to connect other devices to the internet.

Further I have also installed Apache2 on my Pi in the hope of setting up a web server with a simple MySQL database. When I navigate to the Pi's IP address whilst connected to the Pi's wireless access point I get the default Apache 'It Works' page, which is as intended.

However, I am also presented with the 'It Works' page when I navigate to the Pi's IP address whilst connected to the router which the pi is connected to, which is not as intended. I'm sorry if I haven't explained this adequately, I have attempted to simplify what I'm saying below.

(intended behaviour) Primary modem / router > Pi WAP > device > Pi's IP address > 'It works'

(unintended behaviour) Primary modem / router > device > Pi's IP address > 'It works'

To simplify what I'm asking for, Is it possible for the apache server to only be accessible when directly connected to the Pi's access point. Thanks in advance for any help!

Edit as per Ingo's request: When I run the 'ip addr' command I get the following output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
     inet6 ::1/128 scope host 
        valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether b8:27:eb:99:e2:6a brd ff:ff:ff:ff:ff:ff

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether b8:27:eb:cc:b7:3f brd ff:ff:ff:ff:ff:ff

4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b8:27:eb:99:e2:6a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.90/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2a00:23c7:1286:2600:7048:c293:cc42:9f27/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 21474793sec preferred_lft 21474793sec
    inet6 fdaa:bbcc:ddee:0:7b0:74f1:5c8b:2182/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::e9b0:5aa5:4f2b:5b3/64 scope link 
       valid_lft forever preferred_lft forever
11
  • 3
    What are the addresses that should and should not allow connection? If you have a question about Apache, see the Listen directive.
    – RalfFriedl
    Jun 25, 2019 at 5:48
  • 1
    Does the RasPi have two ip addresses? Please address me with @Ingo, otherwise I won't see your reply.
    – Ingo
    Jun 25, 2019 at 8:02
  • 1
    No problem; let's check. You wrote "When I navigate to the Pi's IP address whilst connected to the Pi's wireless access point". What ip address is it? Then you wrote "when I navigate to the Pi's IP address whilst connected to the router". What ip address is that? That's why I ask if the RasPi has two ip addresses. Please can you edit your question (there is a link below the question) and add the output of this command: ip addr.
    – Ingo
    Jun 25, 2019 at 11:42
  • 1
    Listen apache directive configure it with your current IP address : listen only on your interface providing the access point and also apache. 'ip r show wlan0' (assume interface is wlan0), listen on this addr output. restart apache2 service and 'netstat -laputen' and show if apache2 is listening only on your specified IP addr only. Also check that your another configuration of your dns server does not return to the ip address of the server. Use separate DHCP range also can be a solution...
    – Ephemeral
    Jun 25, 2019 at 20:37
  • 2
    @Ephemeral There is a bridge. wlan0 as member of the bridge never has an ip address and is never part of a route.
    – Ingo
    Jun 26, 2019 at 0:30

2 Answers 2

2

You have configured a bridge with slave interfaces eth0 and wlan0. Everything looks good.

You only have one (virtual) interface br0 with an ip address 192.168.1.90. Don't be confused by eth0 and wlan0. As slaves of the bridge they have lost their normal IP characteristics and only work on the OSI data link layer with MAC addresses. The normal interface of the RasPi is br0 with an ip address. Just think that it is anywhere connected to your local network with this interface and ip address like any other device. Apache just uses this single usable interface for its service on port 80. Connect to it and everything is good. If you like to configure anything on Apache just use interface br0.

1

After reading up on the concepts discussed in Ingo's replies I realised my (admittedly stupid) mistake! I had the device configured as a bridge, meaning that the the Pi itself wasn't assigning IP address's to the connected devices, simply providing an interface between the connected devices and the router!

The solution involved a combinational approach of reconfiguring my Pi as an access point in a standalone network - thus allowing the Pi to assign Static IP addresses to connected devices rather than just acting as an extension of the original router, before then configuring apache to only serve devices identifying with an IP address assigned by the Pi itself!

Setting up the Pi as a standalone network such I have done is relatively simple using the guide I posted in my question above, however with one major caveat. In the above guide, when you get to the section about editing dhcpcd.conf you should also add:

server=8.8.8.8 server=8.8.4.4

Such that the complete file looks like:

interface wlan0 static ip_address=192.168.4.1/24 nohook wpa_supplicant server=8.8.8.8 server=8.8.4.4

I had initially attempted setting up the Pi in the standalone network configuration the first time I approached the issue at hand, however without providing a set of DNS servers it resulted in issues with devices refusing to connect correctly, thus leading me to set up my Pi as a bridge as this (seemed to) alleviate the connection issues! However, as discussed above, using a bridge created a million more problems!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.