Iptables NAT configuration interfering with other services communciating to APIs on localhost

[pruhnke]

Before submitting an issue

Please read this first https://github.com/billz/raspap-webgui/wiki/Reporting-issues.

Subject of the issue

NAT rule applies to requests to localhost

Your environment

• Raspberry Pi hardware: Pi 3 Model B+
• Raspbian version: Stretch Lite
• Followed the project prerequisites? Y
• Checked the project FAQ? Y
• RaspAP Quick Install or Manual setup? Quick (i believe)
• Using default configuration? N
• Simultaneous AP and managed mode? N
• Other software or services running with RaspAP? Plex Server

Steps to reproduce

Communicate to a localhost address anyway that is relevant (ping, ssh, etc) and capture packets using tcpdump. Packet source addresses should be seen to be altered. Note: I didn't use this method, it should be applicable. In my case I was testing to the Plex API installed on my system. It's architecture doesn't authenticate requests sourced from localhost (127.0.0.0/8), so I would get 401 errors. Once successful, I would get back 200 responses.

Expected behavior

Ideally, the installation of RaspAP should not require that NAT be performed for packets being sent to a localhost destination as these are always internal system calls, thus no reason to apply NAT.

Actual behavior

In the RaspAP configuration in place for iptables, a single rule is applied to NAT any traffic it sees in POSTROUTING. In my case, this caused a failure in the Plex Server as it had been built to not authenticate communication between service processes of the server. One might suggest that Plex should authenticate all calls, but I assume this practice may be rather common.

I fixed this within my system by adding a NAT rule ahead of the rule RaspAP installed to not apply NAT to connections destined to 127.0.0.0/8.

$ sudo iptables -t nat -I POSTROUTING -d 127.0.0.0/8 -j ACCEPT

$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 31 packets, 4810 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 31 packets, 4810 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 23 packets, 1338 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
17 999 ACCEPT all -- * * 0.0.0.0/0 127.0.0.0/8
2422 158K MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0

[billz]

Thanks for the workaround. I've updated the FAQ with a link back to this issue.