Got this resolved!

The issue is the way StrongSwan (OPNSense IPSec Provider) manages Phase 2
selectors. For the future if anyone runs into this. Just add your networks
into CloudStack like the documentation says to do. Then in your OPNSense
config add additional networks to Manual SPD entries under Advanced options
on the Phase 2 Settings.

CloudStack VPN Customer Gateway

[image: image.png]

OPNSense Phase 2:

[image: image.png]

Thanks!
Wally

On Mon, Feb 19, 2024 at 1:27 PM Wally B <wvbauman...@gmail.com> wrote:

> Tried to change the phase 2 selector at 172.16.192.0/16 to a network on
> the firewall directly (not just a route the firewall knows). Getting the
> same error.
>
> ============ cat /var/log/daemon.log | grep 10.2.200.0/23 ===============
>
> Feb 19 03:45:10 r-407-VM ipsec[174957]: 07[CFG] unable to install policy
> 10.2.200.0/23 === 10.241.0.0/16 in for reqid 4, the same policy for reqid
> 3 exists
> Feb 19 03:45:10 r-407-VM ipsec[174957]: 07[CFG] unable to install policy
> 10.2.200.0/23 === 10.241.0.0/16 fwd for reqid 4, the same policy for
> reqid 3 exists
> Feb 19 03:45:10 r-407-VM ipsec[174957]: 07[CFG] unable to install policy
> 10.241.0.0/16 === 10.2.200.0/23 out for reqid 4, the same policy for
> reqid 3 exists
>
>
>
>
>
> =========== ipsec statusall =============
>
> vpn-xxx.xxx.xxx.171:  xxx.xxx.xxx.154...xxx.xxx.xxx.171  IKEv1,
> dpddelay=30s
> vpn-xxx.xxx.xxx.171:   local:  [xxx.xxx.xxx.154] uses pre-shared key
> authentication
> vpn-xxx.xxx.xxx.171:   remote: [xxx.xxx.xxx.171] uses pre-shared key
> authentication
> vpn-xxx.xxx.xxx.171:   child:  10.241.0.0/16 === 192.168.251.0/26
> 10.2.200.0/23 TUNNEL, dpdaction=restart
>     L2TP-PSK:  172.26.0.151...%any  IKEv1/2
>     L2TP-PSK:   local:  [172.26.0.151] uses pre-shared key authentication
>     L2TP-PSK:   remote: uses pre-shared key authentication
>     L2TP-PSK:   child:  dynamic[udp/l2f] === 0.0.0.0/0[udp]
> <http://0.0.0.0/0%5Budp%5D> TRANSPORT
> Routed Connections:
>     L2TP-PSK{517}:  ROUTED, TRANSPORT, reqid 4
>     L2TP-PSK{517}:   0.0.0.0/0[udp/l2f] <http://0.0.0.0/0%5Budp/l2f%5D>
> === 0.0.0.0/0[udp] <http://0.0.0.0/0%5Budp%5D>
> vpn-xxx.xxx.xxx.171{516}:  ROUTED, TUNNEL, reqid 3
> vpn-xxx.xxx.xxx.171{516}:   10.241.0.0/16 === 10.2.200.0/23
> 192.168.251.0/26
>
>
>
>
> Any help would be appreciated, currently stuck.
>
> Thanks Again
> -Wally
>
> On Sun, Feb 18, 2024 at 12:17 AM Wally B <wvbauman...@gmail.com> wrote:
>
>> I'm working on a site to site connection from my VPC to my on prem
>> OPNsense VPN.
>>
>>
>> Cloudstack Version 4.19.0
>> OPNSense Version 23.4.2
>>
>> I have two P2 selectors setup in OPNsense and i've got a VPN customer
>> gateway setup with two subnets (  192.168.251.0/26,172.16.192.0/20 ) in
>> Cloudstack.
>>
>> The issue im running into is, only the first address in my  VPN customer
>> gateway gets added to the SAD. So, In the above example, since
>> 192.168.251.0/26 is first I can pass traffic to and from the VPC to that
>> subnet on prem. However, 172.16.192.0/20 is not added.
>>
>> I checked the logs on my VPC VR and found the following.
>>
>>
>> Feb 18 06:11:56 r-407-VM charon: 07[CFG] unable to install policy
>> 172.16.192.0/20 === 10.241.0.0/16 in for reqid 3, the same policy for
>> reqid 5 exists
>> Feb 18 06:11:56 r-407-VM charon: 07[CFG] unable to install policy
>> 172.16.192.0/20 === 10.241.0.0/16 fwd for reqid 3, the same policy for
>> reqid 5 exists
>> Feb 18 06:11:56 r-407-VM charon: 07[CFG] unable to install policy
>> 10.241.0.0/16 === 172.16.192.0/20 out for reqid 3, the same policy for
>> reqid 5 exists
>>
>>
>> Wondering if i'm just formatting my  VPN customer gateway CIDRs wrong?
>>
>>
>> Thanks!
>> Wally
>>
>>
>>

Reply via email to