Problem with getting reply packets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
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

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux