ipsec tunnel only accessable from one site

Both sides should have the Remote Gateway set as "Initiate Connection" and the 'Remte Networks' should be those you want to reach via the other Astaro.

On each side, the 'Local Networks' in the 'IPsec Connection' should be the local network(s) you want to allow access to by the other Astaro.

If you need more help, please post pics of the 'IPsec Connection' and 'Remote Gateway' for each Astaro.

Cheers - Bob

I changed bith sides to "initiate", no change happened ... In the file there are pics of the gateway and ipsec tunnel  definitions and the status of the tunnel - this looks allways like that.
Thanks!

At first glance, it looks like the local interface on Astaro 1 should be 'External' instead of 'DMZ'.

the astaro has 3 nics.
Tnak you again for your answer, my explanation:
Teh 3 nics are
eth0 -> "Internal"
eth1 + eth2 = br0 -> "DMZ"
I was not sure, which is a good name, because in fact the
traffic on my "DMZ" is also screened by the firewall - am I right?
Is there another nic necessary? The astaro is vmware - so would be
no problem.
Thanks,
Wolfgang

Now, there's an interesting question - is it possible to configure a Remote Access server on bridged interfaces?  It seems like Wolfgang has proven that it isn't.

Can anyone else report on this?

Cheers - Bob

Well, the tunnel is allways up (pictures in my last post) and one site can allways send data - and after having sent for a non predictive time also the other site can initiate asome communication - so I think, it works on bridged interfaces and there is another problem.
the livelog now:

2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #3: received Vendor ID payload [RFC 3947] 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #3: enabling possible NAT-traversal with method 3 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #3: NAT-Traversal: Result using RFC 3947: no NAT detected 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #3: we don't have a cert 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #3: Peer ID is ID_IPV4_ADDR: 'x.x.x.x' 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #3: ISAKMP SA established 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #4: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#3} 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #4: Dead Peer Detection (RFC 3706) enabled 
2009:08:06-23:14:56 c2 pluto[5498]: "S_Unknown Object" #4: sent QI2, IPsec SA established {ESP=>0xc9681087 

I wonder if one or both of your interfaces might not have an MTU that's causing this problem.  I'm still not convinced that the problems don't stem from the bridging.

For now I solved the problem as follows: Every 10 minutes (an interval of 15 was to long) I send only one ping with 1 byte from that site, that can allways connect - and so the tunnel is stable ... Its really funny because I changed nothing else.

Hmmm...  On the IPsec 'Advanced' tab, if you have the box for 'NAT Traversal (NAT-T)' checked and 'keepalive' at 

NAT-Traversal is checkes and the interval is 60 seconds.
But in the protocol we can see that nat-t is not used, and we
can also see this because both systems can be reached by
public ip-adresses directly...