Problem with getting reply packets

Problem with getting reply packets

[Bart Kus]

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

Re: Problem with getting reply packets

[Pascal Hambourg]

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 ?

Re: Problem with getting reply packets

[Bart Kus]

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