Problem using Pi3 as router into WiFi network

[Bosse_B]

I am trying to use an RPi3 (with Raspbian Jessie) as a router between a wired network and a WiFi network. The WiFi network is actually an Access Point implemented on a data collection system.
This system has a webserver with some pages which allows data retrieval and configuration, which needs to be accessible to the internal network without WiFi.
The idea is the following:
- RPi3 connected by wire to main network
- RPi3 WiFi connected to the data system WiFi SSID
- RPi3 set up as a router by editing the /etc/sysctl.conf and enabling packet forwarding:

Code: Select all

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

- On the Windows7 PC add a route to the WiFi network (1.2.3.0) through the Pi3 (10.0.0.69):

Code: Select all

route -4 ADD 1.2.3.0 MASK 255.255.255.0 10.0.0.69

But when I have done that and rebooted the RPi3 it still does not work
This is what I have on the RPi3:

Code: Select all

 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    202    0        0 eth0
0.0.0.0         1.2.3.4         0.0.0.0         UG    303    0        0 wlan0
1.0.0.0         0.0.0.0         255.0.0.0       U     303    0        0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U     202    0        0 eth0

 ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:e2:6b:1f
          inet addr:10.0.0.69  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3061 errors:0 dropped:0 overruns:0 frame:0
          TX packets:392 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:241857 (236.1 KiB)  TX bytes:54700 (53.4 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:76 errors:0 dropped:0 overruns:0 frame:0
          TX packets:76 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6488 (6.3 KiB)  TX bytes:6488 (6.3 KiB)

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:b7:3e:4a
          inet addr:1.2.3.6  Bcast:1.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:282 errors:0 dropped:271 overruns:0 frame:0
          TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:92971 (90.7 KiB)  TX bytes:15276 (14.9 KiB)

ping 1.2.3.4
PING 1.2.3.4 (1.2.3.4) 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=5.11 ms
64 bytes from 1.2.3.4: icmp_seq=2 ttl=64 time=4.91 ms

So it seems like the Pi is well connected to both networks as was the idea.

Here is the Win7 state:

Code: Select all

route print
...
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.0.1        10.0.0.66     10
          1.2.3.0  255.255.255.240        10.0.0.69        10.0.0.66     11
         10.0.0.0    255.255.255.0         On-link         10.0.0.66    266
        10.0.0.66  255.255.255.255         On-link         10.0.0.66    266
       10.0.0.255  255.255.255.255         On-link         10.0.0.66    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
...

ping 1.2.3.4
Pinging 1.2.3.4 with 32 bytes of data:
Request timed out.

tracert 1.2.3.4
Tracing route to 1.2.3.4 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  rpi3-jessie.xxxx.com [10.0.0.69]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

So when I ping from the Win7 box I get nothing but a timeout error.
And when I try to reach the system's webpage I get a timeout error in FireFox.
But the tracert command seems to indicate that I reach the RPi3 (10.0.0.69)

So what have I done wrong on the Pi?

[Aydan]

For me it sounds as if you'd be better off with a bridge between WLAN and Ethernet.
If you run jessie i hsve no idea how to configure this though. The principle is to create a bridge device on the raspberry and put wlan0 and eth0 into it. then run hostapd on wlan0.
This will allow "connect" all wlan clients into your wired network directly.
If you don't want that i'd suggest using shorewall for the routing option. much easier to set up than iptables directly.

Regards
Aydan

[Bosse_B]

Thanks,
but if I understand your suggestion it involves setting up the RPi3 as an Access Point. But this is the wrong way...
The instrumentation device I need to hook into the office network is itself an access point to which one can connect for instance an Android Tablet and then communicate with the instrument.
What we need is for all PC:s on the network to have this capability by letting the RPi3 connect to the device using WiFi and then act as a packet forwarder from eth0 to wlan0 so the PC:s can use the Pi as a gateway for all accesses to the 1.2.3.x network (yes, this is actually the network of the device!).
I did a similar thing when I was in my home across the Atlantic and needed the RPi:s on my home network have access to the company network. Then I shared the VPN connection on my laptop (Win7) out to a WiFi access point set up on my laptop. One Pi connected to this WiFi AP and it could reach the company LAN after I added a specific route to it. This was necessary because the Pi was dual homed with both eth0 and wlan0.
But then it worked.
After that I could set up routing on the other Pi units and also Win7 PC:s for network 1.2.3.0 to use the Pi IP address as gateway. All of these computers could now access the company LAN.

So I figured that the task of connecting the WiFi AP device to the main network and arrange routing to it would be basically exactly the same, but it seems not...
Even if I delete the automatically created route

Code: Select all

0.0.0.0         1.2.3.4         0.0.0.0         UG    303    0        0 wlan0

and instead add a specific route it will not work.
Right now the routing table looks like this on the Pi3:

Code: Select all

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG    202    0        0 eth0
1.0.0.0         0.0.0.0         255.0.0.0       U     303    0        0 wlan0
1.2.3.0         1.2.3.4         255.255.255.0   UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U     202    0        0 eth0

I cannot get rid of the destination 1.0.0.0, though. It is auto ceated when WiFi connects.
When I try to delete it I get this:

Code: Select all

pi@rpi3-jessie:~ $ sudo route del -net 1.0.0.0 gw 0.0.0.0
SIOCDELRT: Invalid argument
pi@rpi3-jessie:~ $ sudo route del -net 1.0.0.0
SIOCDELRT: Invalid argument

I am sure this is a rather simple thing to solve for a Linux networking guru, but I am failing right now....

[Aydan]

Can you try to configure wlan0 with a static IP? getting rid of dhcp for wlan0 should also solve the problem of the route reappearing.
Is there any way to give this instrument another IP? 1.2.3.x is definitely not the right IP to use for a private network.

the bridge idea won't work if your gadget cannot be a client.
Shorewall is still worth a try for easier routing config.

Do you have access to your network's DHCP config? if so you could add the routing info there. You won't have to add the routes to the machines manually then.

Regards
Aydan

[MattF]

2 things to check:

1: make sure the forwarding chain in iptables has a default permit policy.
2: how do the packets get _back_?

If the host you are tryouts no to reach doesn't know to send the return traffic back via the Pi, it will use its default route and either black hole the traffic or drop it in a firewall due to asymmetric routing.

You probably therefore need a reciprocal static route on the target server.

[Bosse_B]

1: make sure the forwarding chain in iptables has a default permit policy.

How can I know? I do not know how to use the iptables command and reading the help (iptables -h) does not really help either. This is where my experience/knowledge expires and I need guru help.

2: how do the packets get _back_?

Well, I am assuming that if one enables packet forwarding it means that whatever response is given will be returned to the calling device. How else would it happen?

If the host you are tryouts no to reach doesn't know to send the return traffic back via the Pi, it will use its default route and either black hole the traffic or drop it in a firewall due to asymmetric routing.
You probably therefore need a reciprocal static route on the target server.

I do not understand that. If I ping from the RPi3 towards the data collection device on WiFi I get a response back, so the device knows where to send it back. It is just a matter of forwarding the response to the external address that the request came from on eth0....

Let me describe the topology:
- A wired network served by a Windows domain controller regarding DHCP and routing to the Internet.
- On this are several Windows PC:s and also a few Raspberry Pi:s, all have IP addresses given by DHCP.
- In one room there is a stand-alone data collection device, which has a WiFi Access point integrated.
- The device does not have any network connection whatsoever, but any computer connecting to its AP will get an IP address and can then talk to the data collection device via two channels:
A) There is a web server mainly used for configuration of the data collection device
B) Then there is a TCP port to which a client can connect and send data using a proprietary protocol in order to retrieve data collected by the device and command it to perform measurements etc. This was originally an RS232 connection and is now a TCP socket connection with exactly the same protocol as earlier.

Without a routing/packet forwarding system the device can only be connected to by WiFi in the proximity of the device. But we want to be able to reach it from anyplace on the network.

So now the idea is that an RPi3, which is on the main wired network already, connects to the device and then acts as a router for TCP/IP traffic between the wired network and the data collection device via the WiFi connection.

I am able to connect to the device from the RPi3 once WiFi is established and there is no problem returning the requests there.

So there is only one WiFi AP (on the data collection device) and there is one WiFi client (on the RPi3), which connects to the AP.

What needs to be done is making the eth0 network interface on the RPi3 accept incoming requests for an IP address located on the WiFi network and forward that on to the WiFi network wlan0, then send back the response the same way the request came from on eth0.

I am surely missing some crucial component or setting here apart from enabling packet forwarding (which I have done).
But what and how?

EDIT:
I just connected via SSH to the RPi3, which is also connected to the WiFi AP.
Then I issued the command

Code: Select all

 sudo sysctl -p

Since I had not done so after editing the /etc/sysctl.conf file where I uncommented the line:
#net.ipv4.ip_forward=1

Now when I enter a ping command on the pi I get this response:

Code: Select all

pi@rpi3-agi1:~ $ ping 1.2.3.4
ping: icmp open socket: Operation not permitted
pi@rpi3-agi1:~ $ sudo ping 1.2.3.4
PING 1.2.3.4 (1.2.3.4) 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=8.04 ms
64 bytes from 1.2.3.4: icmp_seq=2 ttl=64 time=7.14 ms

Notice that the system does no longer allow user pi to execute ping, why?

[allfox]

Edit: I didn't read the OP's third post when I wrote this!
Edit again: Read the third post, the following still valid. I don't know the "sudo ping" problem.
Another edit: The idea of "if I can send through, then I can receive the same way" is an illusion from the traditional telephone network. This kind of network is cataloged as circuit network. When two end talk to each other, there would be a line between them, and the line would exist through the whole conversation. However computer network is cataloged as datagram network. There is no direct line between most ends. And there is no need for an answer comes back via the same asking path. Even during the conversation, the path between the ends could just change.

Greetings.

I think MattF got the point: there is no way for packet to come back to the wired network.

Using a router instead of a bridge is the right way.

There are some contradictions in your configuration:

Fact 1: I read your Pi's DHCP result about wlan0, it says: inet addr:1.2.3.6 Bcast:1.255.255.255 Mask:255.0.0.0
This means the Wifi network is 1.0.0.0/8. So the automatically generated route to 1.0.0.0/8 is right.

Fact 2: In your Win 7 routing table, there is: 1.2.3.0 255.255.255.240 10.0.0.69 10.0.0.66 11
This means the route is to a network who is 1.2.3.0/28, it's not the Wifi network. However, by some coincidence, this network is just contained in the Wifi network, so packet might go through this route, however, it's not the right way.

Fact 3: In the OP's later post, he said "so the PC:s can use the Pi as a gateway for all accesses to the 1.2.3.x network".
This means he want a route to 1.2.3.0/24 network. It would be the third network in this post, it's neither the Wifi network, nor known by Win 7.

I would suggest OP get these straight first. Like Aydan said, it would be better to use a private address space: https://en.wikipedia.org/wiki/Private_network


The problem might be like this:

1 - Win 7 want to ping 1.2.3.4. So it read its routing table, and found that 1.2.3.4 is in the network 1.2.3.0/28, then it would send this ping packet to 10.0.0.69, who is the Pi eth0.

2 - Pi see the packet is for 1.2.3.4, so it read its routing table, found that 1.2.3.4 is in the network 1.0.0.0/8, then forward it to wlan0. There should be an ARP process here, Pi would ask "who is 1.2.3.4" via wlan0, and the AP would answer "I am".

3 - The AP received the ping packet, and want to answer it. However, the incoming packet's source is Win 7's address, which would be 10.0.0.66. The AP's routing table might not have this. The OP didn't post the AP's routing table. If the AP don't know the route, it would use the default route, which just pointing to itself. So the answer packet couldn't be sent.


Two different solutions here:

1 - Tell the AP about the route to the wired network by adding a route to 10.0.0.0/24 via 1.2.3.6. The 1.2.3.6 is the Pi wlan0 address, if your DHCP server can not maintain this address for it, then you need a static address, just like Aydan said.

2 - Enable NAT on the Pi to translate the source address, iptables -A POSTROUTING -o wlan0 -j MASQUERADE. This command would not maintain after reboot, so test it before reboot. You could make it permanent.

[Bosse_B]

Using a router instead of a bridge is the right way.

I'm fine with that, in fact I did actually want to do that but did not know how...

Like Aydan said, it would be better to use a private address space: https://en.wikipedia.org/wiki/Private_network

I agree again, but in this case the target WiFi AP is a small WiFi module tied to the RS232 connection in the data collection device.
It happens to have an operational mode to create an AP so one can connect to it via WiFi. Thereafter the communications is via a TCP socket port on the WiFi device which hooks into the device serial lines. No way to handle any of the networking stuff you mention.
And the IP address is hard coded.

Two different solutions here:

1 - Tell the AP about the route to the wired network by adding a route to 10.0.0.0/24 via 1.2.3.6. The 1.2.3.6 is the Pi wlan0 address, if your DHCP server can not maintain this address for it, then you need a static address, just like Aydan said.

I cannot do anything about the way the WiFi module operates, it is factory set by the maker of the module...

2 - Enable NAT on the Pi to translate the source address, iptables -A POSTROUTING -o wlan0 -j MASQUERADE. This command would not maintain after reboot, so test it before reboot. You could make it permanent.

I tried setting this iptables entry but it failed:

Code: Select all

pi@rpi3-agi1:~ $ sudo iptables -A POSTROUTING -o wlan0 -j MASQUERADE
iptables: No chain/target/match by that name.

Is there some tutorial dealing with using an RPi3 as a router to a "dead end" network?
The device WiFi only accepts 4 or 5 connected clients and there is no network past it such as the Internet...

[allfox]

I tried setting this iptables entry but it failed:
pi@rpi3-agi1:~ $ sudo iptables -A POSTROUTING -o wlan0 -j MASQUERADE
iptables: No chain/target/match by that name.

Excuse me for that. I told you the wrong command.

Try this again:
sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

The rule should be in NAT table, however by default, the command modify the FILTER table.

Wish it works.