[Openswan Users] Problem with tunnel configuration with an ip alias

[David]

Hi to all.

I'm trying to establish a tunnel betwteen two subnets
NET A: 172.16.0.0/24
NET B: 172.16.253.0/24

Both Gateways aren't nated. (they have public ip addr).

The diferences between them are:
Gateway A has 2 ethernet interfaces (a public and a private),
and has already configured ipsec with other 3 tunnels to 3 other subnets 
(172.16.1.0/24, 172.16.2.0/24
and 172.16.3.0/24) which work perfecly.
The ips for Gateway A are 213.x.x.x and 172.16.0.22


Gateway B has only one ehternet interface with 2 ip addr
the public is 91.x.x.x
and the private is 172.16.253.22


The problem is that I can't comunicate with
Gateway B, from subnet A or Gateway A,
nor the opposite direction (ping from gateway B to
host or gateway A)

What I don't understand is that the tunnels and routes seems correct and
traffic seems to flow correctly:


I'm doing this test:
Ping From GW B to host inside network A
ping 172.16.0.10
(the ping program does not show the response, nor timeout....,
nothing for more than 5 minutes.)

--- 172.16.0.10 ping statistics ---
2157 packets transmitted, 0 received, 100% packet loss, time 2158627ms


Dump in internal interface of Gateway A
tcpdump -i eth1 -p icmp -n

08:25:11.704502 IP 172.16.253.22 > 172.16.0.10: icmp 64: echo request seq 0
08:25:11.704620 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 0
08:25:12.703272 IP 172.16.253.22 > 172.16.0.10: icmp 64: echo request seq 1
08:25:12.703395 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 1
08:25:13.704340 IP 172.16.253.22 > 172.16.0.10: icmp 64: echo request seq 2
08:25:13.704462 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 2
08:25:14.715512 IP 172.16.253.22 > 172.16.0.10: icmp 64: echo request seq 3
08:25:14.715642 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 3
08:25:15.715551 IP 172.16.253.22 > 172.16.0.10: icmp 64: echo request seq 4
08:25:15.715668 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 4
08:25:16.716109 IP 172.16.253.22 > 172.16.0.10: icmp 64: echo request seq 5
08:25:16.716220 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 5

Dump in interface of Gateway B
(I assume that echo request is not shown because is encrypted)
tcpdump -i eth0 -p icmp -n

08:25:10.450443 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 0
08:25:11.449509 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 1
08:25:12.450756 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 2
08:25:13.461661 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 3
08:25:14.461469 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 4
08:25:15.462522 IP 172.16.0.10 > 172.16.253.22: icmp 64: echo reply seq 5


Iptables in Gateway B (all accepted)
# Generated by iptables-save v1.3.0 on Mon May  5 08:16:27 2008
*raw
:OUTPUT ACCEPT [952992:83908424]
:PREROUTING ACCEPT [447695:58547634]
COMMIT
# Completed on Mon May  5 08:16:27 2008
# Generated by iptables-save v1.3.0 on Mon May  5 08:16:27 2008
*nat
:OUTPUT ACCEPT [813498:65134927]
:POSTROUTING ACCEPT [813500:65135007]
:PREROUTING ACCEPT [130903:14203419]
COMMIT
# Completed on Mon May  5 08:16:27 2008
# Generated by iptables-save v1.3.0 on Mon May  5 08:16:27 2008
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [447626:58541010]
:OUTPUT ACCEPT [952992:83908424]
:POSTROUTING ACCEPT [952893:83905531]
:PREROUTING ACCEPT [447695:58547634]
COMMIT
# Completed on Mon May  5 08:16:27 2008
# Generated by iptables-save v1.3.0 on Mon May  5 08:16:27 2008
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT


I don't think that problem is ipsec configuration.
(it is the same configuration of the other 3 tunnels.)

Some of you could giveme a clue of what could be the problem?
It seems as if kernel does not pass to application the information received
from transport layer....?

In fact, the kernel had to be recompiled, because the original didn't had
support for modules, and it lacked support for CryptoAPI.

If further information is needed, please ask. (I don't want to

Thanks in advance.