Problem with getting reply packets

Hey everyone, I would greatly appreciate some help with the following problem.

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:

# Generated by iptables-save v1.3.5 on Wed Jan 28 19:08:14 2009 *filter
:INPUT ACCEPT [4336:476922]
:FORWARD ACCEPT [2565:152535]
:OUTPUT ACCEPT [4208:1526248]
:FIREWALL - [0:0]
-A INPUT -j FIREWALL
-A FORWARD -j FIREWALL
COMMIT
# Completed on Wed Jan 28 19:08:14 2009
# Generated by iptables-save v1.3.5 on Wed Jan 28 19:08:14 2009 *nat
:PREROUTING ACCEPT [266:57188]
:POSTROUTING ACCEPT [1378:65372]
:OUTPUT ACCEPT [54:4039]
-A PREROUTING -i ath0 -p tcp -m tcp --dport 443 -j ACCEPT -A PREROUTING -i ath0 -j DNAT --to-destination 192.168.44.17 -A POSTROUTING -o ath0 -j MASQUERADE
COMMIT
# Completed on Wed Jan 28 19:08:14 2009

Here's the routing table on WifiRouter:

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.44.16   0.0.0.0         255.255.255.240 U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 ath0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 ath0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 ath0

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

98.233.248.36 is the remote IP trying for an in bound connection. 192.168.1.200 is the WifiRouter's IP on the private Netgear net. 192.168.44.18 is the other WifiRouter IP but on the private net with CoreRouter. 192.168.44.17 is the CoreRouter's IP on the private net with WifiRouter.

Here's a packet capture on the CoreRouter interface to show the incoming and reply packets:

15:46:17.132370 IP (tos 0x20, ttl 48, id 16938, offset 0, flags [DF], proto TCP (6), length 64) 98.233.248.36.50587 > 192.168.44.17.22: S, cksum 0xedf4 (correct), 1412062838:1412062838(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 406286523 0,sackOK,eol> 15:46:17.132502 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.44.17.22 > 98.233.248.36.50587: S, cksum 0x61ec (correct), 817829122:817829122(0) ack 1412062839 win 5792 <mss 1460,sackOK,timestamp 342830119 406286523,nop,wscale 6>

I verified that the MACs are also correct via WireShark.

Why is the reply (SYN+ACK) not being associated with this SYN_RECV state entry and being propagated back out to the internet?

--Bart

Hello,

[...]

[...]

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.

No clue, sorry. Did you try to trace it through the iptables chains ?

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