[Solved] Cannot get NAT to work any more

[keithspg]

I have an (actually many, Pi1B, Zero, Pi2, 3B, 3B+) RPi running Arch (ipv6 enabled if that is important).
The RPi is connected:
$this->bbcode_second_pass_code('', 'root:/srv/http/command# ping www.google.com
PING www.google.com(ord38s31-in-x04.1e100.net (2607:f8b0:4009:81a::2004)) 56 data bytes
64 bytes from ord38s31-in-x04.1e100.net (2607:f8b0:4009:81a::2004): icmp_seq=1 ttl=117 time=4.03 ms
64 bytes from ord38s31-in-x04.1e100.net (2607:f8b0:4009:81a::2004): icmp_seq=2 ttl=117 time=4.11 ms
64 bytes from ord38s31-in-x04.1e100.net (2607:f8b0:4009:81a::2004): icmp_seq=3 ttl=117 time=4.04 ms
64 bytes from ord38s31-in-x04.1e100.net (2607:f8b0:4009:81a::2004): icmp_seq=4 ttl=117 time=4.00 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 4.000/4.044/4.106/0.038 ms
root:/srv/http/command# ping -4 www.google.com
PING (142.250.191.196) 56(84) bytes of data.
64 bytes from ord38s31-in-f4.1e100.net (142.250.191.196): icmp_seq=1 ttl=117 time=3.96 ms
64 bytes from ord38s31-in-f4.1e100.net (142.250.191.196): icmp_seq=2 ttl=117 time=3.59 ms
64 bytes from ord38s31-in-f4.1e100.net (142.250.191.196): icmp_seq=3 ttl=117 time=3.80 ms
^C
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 3.586/3.782/3.961/0.153 ms')
I believe I have ip forwarding enabled:
$this->bbcode_second_pass_code('', 'root:~# cat /proc/sys/net/ipv4/ip_forward
1')
I can connect to the RPi as an AP, but I have no internet connectivity.
I was previously able to get NAT to work with hostapd/dnsmasq by these iptable commands:
$this->bbcode_second_pass_code('', 'iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT')
This no longer works.
I have also tried iwd and can also connect but also get no internet connectivity. Previously with iwd, I used these iptable rules:
$this->bbcode_second_pass_code('', 'iptables -t nat -A POSTROUTING -s 192.168.5.0/24 -j MASQUERADE')

Any idea what I am doing wrong? Has something changed which stops this from working?

Regards,

Keith

[keithspg]

I was able to poke away and brute force it to work with iwd, but would like to know how to properly resolve this.
The RPI has a DHCP connection on its eth0 connection and gets its DNS from the router. I have a pihole set up and the its address is 192.168.2.3 and all my LAN/WiFi clients connected to the router get this as a DNS server when they connect to DHCP.

Previously with dnsmasq/hopstapd, I set the gateway and DNS in the /etc/dnsmasq.conf file:

$this->bbcode_second_pass_code('', 'dhcp-option=option:dns-server,192.168.5.1')

I think this worked at one time, but does not any more. I tried setting this to 8.8.8.8 and still no connection.

On the iwd side, I was able to get it to NAT by putting in google as the DNS server (8.8.8.8) in its config and can connect and NAT.

What is the proper way to set this up (or iwd for that matter) so that clients connected to the RPi WiFi use the DNS server provided on eth0? Do I need to set up a specific route for the wifi clients to get there?

Keith

[summers]

As I understand it you are using the RPi as a router - and it has at least two net network connections?

I do that with my beagle network, that is plugged into my NAS via usb, and the NAS is connected to my router which goes to the WAN.

Now the NAS has all interfaces, these are the ipv4 ones:
$this->bbcode_second_pass_code('', 'ip a
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
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 5c:f4:ab:51:71:8f brd ff:ff:ff:ff:ff:ff
inet 192.168.2.144/24 brd 192.168.2.255 scope global dynamic eth0
valid_lft 36849sec preferred_lft 36849sec
6: usb1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether ba:dd:0f:97:37:9c brd ff:ff:ff:ff:ff:ff
inet 192.168.7.1/30 brd 192.168.7.3 scope global dynamic usb1
valid_lft 2008sec preferred_lft 2008sec
9: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether ce:13:b3:e1:b4:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.7.17/30 brd 192.168.7.19 scope global dynamic usb0
valid_lft 2690sec preferred_lft 2690sec
')
It has routing set up
$this->bbcode_second_pass_code('', 'ip r
default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.144 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.144
192.168.2.1 dev eth0 proto dhcp scope link src 192.168.2.144 metric 1024
192.168.7.0/30 dev usb1 proto kernel scope link src 192.168.7.1
192.168.7.16/30 dev usb0 proto kernel scope link src 192.168.7.17 ')
And it has a firewall done via nftables
$this->bbcode_second_pass_code('', 'nft list ruleset
[sudo] password for summers:
table ip nat {
chain prerouting {
type nat hook prerouting priority filter; policy accept;
}

chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
masquerade
}
}
table inet filter {
chain input {
type filter hook input priority filter; policy accept;
ct state { established, related } accept
ct state invalid drop
iifname "lo" accept
ip protocol icmp accept
ip6 nexthdr ipv6-icmp accept
tcp dport 22 accept
meta nfproto ipv4 reject
}

chain forward {
type filter hook forward priority filter; policy accept;
}

chain output {
type filter hook output priority filter; policy accept;
}
}
')
The beagle networks have a set up like this:
$this->bbcode_second_pass_code('', '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
2: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether fa:23:d6:9e:e9:8d brd ff:ff:ff:ff:ff:ff
inet 192.168.7.18/30 brd 192.168.7.19 scope global usb0
valid_lft forever preferred_lft forever
')
$this->bbcode_second_pass_code('', 'ip r
default via 192.168.7.17 dev usb0 proto static
192.168.7.16/30 dev usb0 proto kernel scope link src 192.168.7.18')
And this works, and the beagles can connect to the internet. Oddly it only works with the NAT enabled, even though the router knows where the beagles live:
$this->bbcode_second_pass_code('', 'ip r
default via aa.bb.cc.dd dev pppoa-wan
192.168.2.0/24 dev br-lan scope link src 192.168.2.1
192.168.7.0/24 via 192.168.2.144 dev br-lan
aa.bb.cc.ee dev pppoa-wan scope link src 11.22.33.44')
But anyway does work with the NAT on the NAS. So only difference to yours is that I'm using nftables, and the NAS hasn't been updated ion some time (root partition is too small ...)

[summers]

Wondered why with IP forwarding I needed a NAT, especially as all routing is set up on my LAN.

Just dug a bit, turns out that my router with runs openwrt, the dns server there considers my beagle network as being outside the LAN, and so refuses to give out information. So on the beagle network changing the DNS server to 8.8.8.8.8 e.g. google - and the net works without the NAT on the gateway machine!

So NAT isn't necessary for IP forwarding ...

[keithspg]

Well, I finally figured this out. I had changed the port in dnsmasq.conf to 5300 instead of 53 and that is why DNS was failing for hostapd/dnsmasq. I set it pack to port 53 and all was well. I could once again use the IP address of the hostapd interface to do the DNS lookup as long as teh eth0 interface was connected and had a valid DNS server.

iwd does not seem to work this way, though. With iwd in AP mode, you need to put in a valid IP address for the DNS server in the configuration and not the IP address of the AP interface. The example uses the google address of 8.8.8.8, but I was able to get it to work by using my local server of 192.168.2.3. It is a bit of a pain that you have to do this instead of using the AP IP address, but it does seem to be how it works.