Packets get dropped

Packets get dropped

[Christian Weber]

Dear list압 members,

we recently found tcp packets to get dropped an a machine
behind a firewall with only 1 physical nic doing 'Y' routing
between IPSEC tunnel an LAN.

The machine is located in a dmz but was granted to be the end
of a (2.6.5 kernel ipsec) tunnel. The ipsec interface is unvisible.

The sole connection to any other relevant host goes to a firewall
the box is connected with.

We want to pass packets from <remote_net> to <local_net> through
the tunnel, as if they came from from the y-router itself.

So we configured:
# iptables -I FORWARD -s <remote_net> -d <local_net> -j ACCEPT
# iptables -I FORWARD -d <remote_net> -s <local_net> -j ACCEPT
# iptables -P FORWARD DROP  ; # REJECT does not work here ..

# echo "1" > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -I POSTROUTING -s <remote_net> -j MASQUERADE

Trying some ssh to a machine (let압 call it "dest") located in local_net
fails. The SYN goes through, leaves the <-router압 interface, gets answered
(ACK from dest) comes in and ... is being dropped without a trace.

There is an entry in the conntrack table:
tcp      6 25 SYN_RECV src=xx.xx.xx.111 dst=192.168.250.228 sport=1714 dport=22
	src=192.168.250.228 dst=yy.yy.yy.5 sport=22 dport=1714 use=1

The answered packet (SYN ACK) came from 192.168.250.228:22 (according to tcpdump)
and was destined to yy.yy.yy.5:1714

In some list we found a hint according masquerading problems with ipsec. The
possible solution presented there was to add (and we tried):

# iptables -t nat -I POSTROUTING -p 50 -j ACCEPT

That cound avoid confusion, but that didn앖 help.

Any help appreciated.

---

BTW: on another machine (same hardware but two nic압) with same config (but the nic
and tunnel adresses) and the same kernel, there is no problem when really routing
through the machine, i.e. when the packet comes throuh the ipsec tunnel which is
connected over the outer interface, is masqueraded and emiited through the inner
interface, aswered by dest and send back....

Any idea?

---

Oh, one more question - just for understandig the system a bit better (since i couldn앖
find the answer in any howto i read) .

How is the incoming packet picked up when it comes in. When it comes in it gets examined
by the kernel. OK so far. Who looks up the conntrack table if it matches an associated
connection and rewrites the headers if it does match - performing the reverse nat of
masquerading?

Thanks in advance
-- 
Christian Weber
mailto:Weber@InfoTech.de    Tel: 02361/91300
For information on InfoTech visit http://www.InfoTech.de/