Re: Problem with getting reply packets

[Bart Kus <me@bartk.us>]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html