A-HA! Thank you for the insight about SYN_RECV. It led me to think
about the sanity of my remote test site that I was using to cause these
inbound connections. It seems that during the past 3 months the remote
site's firewall policies have changed and they now block port 22
outbound! Tested from an alternate remote site and everything works as
it should.
Thanks again!
--Bart
Pascal Hambourg wrote:
Hello,
Bart Kus a écrit :
Setup: Inet -> Netgear -> WifiRouter -> CoreRouter
Connection comes from inet to Netgear's public IP. DMZ on Netgear
takes it to WifRouter's IP within the internal net of Netgear. DMZ
on WifiRouter takes it to CoreRouter's IP. CoreRouter is running
sshd and replies to WifiRouter. WifiRouter does NOT forward the
packet to Netgear. A state is established in ip_conntrack but never
matures beyond SYN_RECV status. Here's the iptables of WifiRouter:
[...]
And here's the relevant ip_conntrack entry of WifiRouter after a SYN
has been sent, and CoreRouter has properly transmitted a SYN+ACK back
@ WifiRouter:
tcp 6 59 SYN_RECV src=98.233.248.36 dst=192.168.1.200
sport=50587 dport=22 src=192.168.44.17 dst=98.233.248.36 sport=22
dport=50587 use=1
[...]
Why is the reply (SYN+ACK) not being associated with this SYN_RECV
state entry
It is. The SYN_RECV states indicates that the SYN+ACK was successfully
associated to the connection. Otherwise the conntrack entry would show
SYN_SENT and [UNREPLIED] instead.
and being propagated back out to the internet?
No clue, sorry. Did you try to trace it through the iptables chains ?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
