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´s call it "dest") located in local_net fails. The SYN goes through, leaves the <-router´s 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´t help.
Any help appreciated.
---
BTW: on another machine (same hardware but two nic´s) 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´t 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@xxxxxxxxxxx Tel: 02361/91300 For information on InfoTech visit http://www.InfoTech.de/
