Le 26/12/2017 à 14:55, Mark Fletcher a écrit :
I would also expect that if it did not know
that, it would send packets for 192.168.1.3 to 192.168.1.1 for
forwarding, just as it does every packet that is destined for the
internet -- and I would expect the firewall to be able to forward them,
since it can clearly see the PI.
A firewall usually has filtering rules. Do these rules allow packets to be
forwarded from the LAN interface back to the same interface ?
Also, this would cause asymmetric routing (the server would send reply
packets directly to the client), which may not work well with stateful
filtering as the firewall would see only one direction of the communication.
Fair question re routing rules.
Filtering rules, not routing rules.
Routing rules determine how a packet should be routed.
Filtering rules such as iptables rules determines whether a packet
should be dropped or accepted.
The firewall's routing rules are (amongst other rules
which I don't believe relevant -- and external interface name elided):
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD ! -i <external interface> -m conntrack --ctstate NEW
-j ACCEPT
...which I think should allow it to route from the inside interface to
the inside interface.
It should work with ICMP echo (ping) and UDP (used for DNS). But IIRC it
would not work with TCP (used by SSH) because the firewall does not see
the reply packets (including the SYN/ACK in the 3-way handshake) sent by
the server directly to the client, so the subsequent packets from the
client would be flagged in the INVALID state and not accepted by these
rules.
No, the airstation having been given an address 192.168.1.x/24 will know
that it can directly reach any host 192.168.1.1 through 192.168.1.254
inclusive.
Maybe I missed something but I read no evidence in the OP's posts that the
netmask on the Airstation WAN side is actually /24. If for instance the mask
was set to /30 instead, 192.168.1.3 would be considered by the Airstation as
a broadcast address and would explain why it does not work.
The netmask is 255.255.255.252. I just tried changing it to 248, ie
zeroing out one more bit, but that did not help. (changed it by changing
the netmask supplied by the firewall's DHCP server and then checking in
the AirStation's web interface that the netmask had indeed changed).
Netmask 255.255.255.252 with network 192.168.1.0 (or 192.168.1.0/30)
implies that 192.168.1.3 is a broadcast address and cannot be used as a
unicast host address. Even though the Airstation accepted to forward
packets sent to this address, the packets would be sent on the WAN link
to the broadcast ethernet address (ff:ff:ff:ff:ff:ff) and discarded by
the server for this reason (a packet must not have a unicast IP address
and a broadcast ethernet address).
With netmask 255.255.255.248 (192.168.1.0/29), the broadcast address is
192.168.1.7 and 192.168.1.3 is considered as a unicast host address so
the above issue should disappear.
But why do you bother with such narrow subnets and just don't use
255.255.255.0 (/24) ? It has been reported that some devices and OSes
don't behave well with "unusual" netmasks (having values other than 255
and 0).
Also, I recommend that you run a packet capture on the firewall and the
server to see what's going on when you try to communicate to the server
from the internal network.
tcpdump -nei <interface>
