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>