On Wed, 1 Mar 2017, Christoph wrote:

I have here a tunnel between libreswan 3.15 and cisco asa (9.1). For the network where the libreswan has an ip inside it does work goos, but I have a network 'behind' libreswan host and if I ping to it, the tunnel doesnt go online.

That most likely relates to firewalling, forwarding, rp_filter, etc.

config setup
  protostack=netkey
  listen=$STATIC_INET_IP

In general, I would not use the listen= argument and let libreswan
listen to ANY. But that's unrelated to your issue.

conn home
         ike=aes256-sha256;modp1024
                  esp=aes256-sha1;modp1024
         initial_contact=yes
         aggrmode=yes
         authby=secret
         left=$STATIC_INET_IP
         leftid=$STATIC_INET_IP
         leftsourceip=192.168.55.1
         remote_peer_type=cisco
         right=$MY_DYNDNS_ON_CISCO_ASA
         rightid=192.168.40.2
         right=%any
         salifetime=24h
         ikelifetime=24h
         dpdaction=restart
         dpdtimeout=60
         dpddelay=30
         ikev2=insist
         disablearrivalcheck=no
         auto=start

conn chao5.int-bio
         also=home
         leftsubnet=10.0.0.0/8
         rightsubnet=192.168.50.0/24

conn chao5.int-behemoth
         also=home
         leftsubnet=192.168.55.0/24
         rightsubnet=192.168.50.0/24

Since you are using also=home, you cannot specify leftsourceip= since
that only makes sense if leftsourceip= is part of leftsubnet. And
for subnets "behind" the libreswan server, I assume you have no
sourceip and you get those packets via routing.

Do not use remote_peer_type=cisco unless using XAUTH.

Use dpdaction=hold (especially on older libreswan versions) to avoid
a packet leak.

disablearrivalcheck= is KLIPS only - you can and should remove it.

Note you say "on demand" but you have auto=start, meaning the tunnels
should immediatelly all come up without needing a packet trigger.

And since auto=start is in the conn home, you will have 3 tunnels
that are trying to get established, while I think the cisco has
not non-subnet configuration for you. So I would move the auto=start
to inside chao5.int-bio and chao5.int-behemoth

what can be the problem?

I'd have to see the logs, or the output of:

ipsec auto --replace home
ipsec auto --replace chao5.int-bio
ipsec auto --replace chao5.int-behemoth
ipsec auto --up chao5.int-bio
ipsec auto --up chao5.int-behemoth

Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to