That will work if there's no NAT in between the hosts. Otherwise the proposed TSi and TSr will not match, because the perceived remote peer's IP will be different from what it proposes as TS.
On 16.03.2017 19:37, Muhammad Yousuf Khan wrote: > Thanks you for your input Noel. it is really appreciated. > So you mean i delete leftsubnet parameter thats is sufficient and tunnel will > work. > > Thanks, > Yousuf > > On Thu, Mar 16, 2017 at 10:36 PM, Noel Kuntze <[email protected] > <mailto:[email protected]>> wrote: > > On 16.03.2017 07:29, Muhammad Yousuf Khan wrote: > > > > There is a requriment from our client that we need a ipsec tunnel for > communication. > > as per our experience with Openvpn we can do that very easily however > IPsec works very differently therefore i need your assistence. > > Policy based IPsec (which is used by default with strongswan) doesn't > require special network devices. > Traffic is protected transparently on the physical interface. There's no > problem with routing. > > > now here is the confusion part leftsubnet is technically called > encryption domain in Cisco. > > so how come my public IP of a cloud VM can be in both role as remote > peer and encryption domain? this is very confusing part. > > IKE packets are excepted from IPsec processing. Anything else is subject > to it. It works without adding special routes > to the routing table(s). > > > -- > > Mit freundlichen Grüßen/Kind Regards, > Noel Kuntze > > GPG Key ID: 0x63EC6658 > Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 > > > -- Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
