[Openswan Users] strange problem with openswan and local services on vpn gateway

[M L]

Hello,
I have some strange problem with Linux Openswan U2.6.23/K2.6.26-2-686
(netkey) on Debian.
My setup:
2 networks ( 192.168.106.0/24 <->  192.168.101.112/29) connected via ipsec:

192.168.106.0/24 (my peer side via Checkpoint )
      |
my peer external gateway IP A.B.C.D
      |
(Internet)
      |
my external gateway IP X.Y.Z.V
      |
my internal vpn server 192.168.2.191 + eth0:1 alias 192.168.101.113
(192.168.101.113 has local services provided for my peer)


network 192.168.106.0/24 should see 192.168.101.113 host and
connections initiated from 192.168.101.113 should reach
192.168.106.0/24

tunel is established w/o problems and I can connect from my vpn
server/gateway (via tcp) to any services located in  192.168.106.0/24
network (my peer's network).

My vpn server/gateway has eth0 (my local network) and eth0:1 alias
used for receiving connections from 192.168.106.0/24:

eth0    Link encap:Ethernet  HWaddr 00:0c:29:fb:86:8e
          inet addr:192.168.2.191  Bcast:192.168.2.191  Mask:255.255.255.192
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

eth0:1    Link encap:Ethernet  HWaddr 00:0c:29:fb:86:8e
          inet addr:192.168.101.113  Bcast:192.168.101.119  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:18 Base address:0x1400

vpn gateway runs local apache proxy which listens for connections on
all interfaces (including 192.168.101.113).
Local connections (initiated from 192.168.101.113 and to
192.168.101.113)   works:

vpn:~#   telnet 192.168.101.113 443
Trying 192.168.101.113...
Connected to 192.168.101.113.
Escape character is '^]'.

When my peer try telnet 192.168.101.113 443 it gets timeout.

When I run tcpdump on my eth0 at vpn I see encrypted packed and
immediately decrypted packet (note the same timestamp):

21:36:57.529540 IP A.B.C.D > 192.168.2.191:
ESP(spi=0x9a4e3b51,seq=0x3d), length 92
21:36:57.529540 IP 192.168.106.133.41233 > 192.168.101.113.443: S
3350716436:3350716436(0) win 5840 <mss 1360,sackOK,timestamp
1002325407 0,nop,wscale 6>

above 2 lines are repeated many times (syn w/o ack ?)
It's looks like packet are not "delivered" to upper layer and
connection to apache process (at 443 port) is not established. I don't
use any iptables filter rules,
default policy is ACCEPT for all chains.
First my thoughts was: packed are droped (unknown reason) before
reaching INPUT chain, but when I add a testing rule:

iptables -I INPUT  -i eth0 -d 192.168.101.113 -p tcp   --dport 443 -j REJECT

my peer gets connection refused (before was only timeout), and tcpdump
shows extra reply packed (timestamp 22:02:09.553417):

22:02:09.553073 IP A.B.C.D > 192.168.2.191:
ESP(spi=0xa8fd34e3,seq=0x27), length 92
22:02:09.553073 IP 192.168.106.133.45105 > 192.168.101.113.443: S
1302153132:1302153132(0) win 5840 <mss 1360,sackOK,timestamp
1002703423 0,nop,wscale 6>
22:02:09.553417 IP 192.168.2.191 > A.B.C.D:
ESP(spi=0x0c356e78,seq=0x69), length 124  <-- (connection refused
reply packed?)

So above is the proof that packed travel via INPUT chain, so I removed
testing REJECT rule.

Which possible reasons (when nothing is filtered) could cause such
problems that packed is delivered to INPUT chain but connection is not
"passed"
to application layer?

vpn routing table:
vpn:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.101.112 0.0.0.0         255.255.255.248 U     0      0        0 eth0
192.168.2.128   0.0.0.0         255.255.255.128 U     0      0        0 eth0
0.0.0.0         192.168.2.177   0.0.0.0         UG    0      0        0 eth0

regards,
-- 
Marico