Introduction

This is how to access PowerVS using VPN for VPC(site-to-site VPN) that can be used in a VPC.
I have written a similar article in the past, but in May 2024, a new feature was released around VPC networking that makes it even easier to connect than before.

This article is written assuming a PER (Power Edge Router) environment, but I believe it is possible to do the same in an environment connected via Cloud Connections(Direct Link 2.0).

The key points are as follows.

If we configure it without considering anything special (what I will write in this article), PowerVS does not know the routing information to the IP address range of on-premises, so it is not possible to send packets from PowerVS to on-premises.　
It is now possible to propagate routing information based on the policy configured in VPN for VPC from the VPN Gateway to the routing table of the VPC and then propagate it to the Transit Gateway(this is the new feature in May 2024). This feature allows the VPC to advertise routing information to the on-premises IP address range to PowerVS side and PowerVS to send packets destined to on-premises IP range to VPC.
VPN Gateway passes the packets to the on-premises via VPN tunnel, enabling end-to-end communication.

Before this feature was introduced, it was necessary to create a prefix for the on-premises IP address range in the VPC, but this is no longer necessary with the new May 2024 feature.
How to connect to a VPN using a prefix is described below.
https://qiita.com/y_tama/items/50791f4c2256d2801804

An overview image is shown below.

Connecting on-premises and VPC with site-to-site VPN.

Connect on-premises and VPC with site-to-site VPN on VPC. Note that the VPN configuration on IBM Cloud side must be made with a policy based.

This configuration will not work if the VPN setting on the IBM Cloud side is route based.

For Local IBM CIDRs, specify the PowerVS subnet, not the VPC subnet.
For the Peer CIDRs, just specify the subnet of the on-premises as usual.

On the opposite on-premises VPN router, also specify the PowerVS subnet, not the VPC subnet, for the Peer CIDRs.

Connect PowerVS to Transit Gateway

Connect PowerVS in PER environment to Transit Gateway.

If the LPAR has a Public IP, the default gateway is set to the public side. Configure static routes on the LPAR so that packets destined for on-premises are routed to the private-side gateway.

# netstat -r
Routing tables
Destination        Gateway           Flags   Refs     Use  If   Exp  Groups

Route tree for Protocol Family 2 (Internet):
default            192.168.179.25    UG        6   6207270 en0      -      -   
10.50.50/24        172.16.42.1       UGS       0      1184 en1      -      -   
127/8              localhost         U         4    945769 lo0      -      -   
...

Connect the VPC to the Transit Gateway

Create a BGP report on the Transit Gateway and check the routing information, and you will see that route information is being advertised from PowerVS and the VPC.
At this point, the only route information advertised from the VPC is 10.40.40.0/24, which is defined in the VPC prefix.
In a subsequent step, the route information to 10.50.50.0/24 on-premises will be made ready to be advertised from the VPC to the Transit Gateway.

Define ingress routing table on VPC

Create a new ingress routing table in the VPC.
Select VPN gateway as Accepts routes from so that the route information configured at VPN Gateway will be automatically reflected in the route table.

Enable Transit Gateway as Traffic source, and also set Advertise to to On in the expansion.

A route table is created and the route information is automatically propagated from the VPN gateway.
For packets destined to 10.50.50.0/24, which were set as the Peer CIDR in the VPN settings, the next hop is set to the VPN Gateway's IP address (10.40.40.40.4).
Also, the Advertise column is On, and this information is being advertised to the Transit Gateway.

Create the Transit Gateway BGP report again and verify that the routing information to the on-premises IP address range is advertised from the VPC to the Transit Gateway.

Once the packets reach the VPN Gateway, the VPN Gateway knows the route to the on-premises beyond, so it can deliver the packets to the on-premises through the VPN tunnel.

This enables communication from the on-premises to PowerVS.

Below is a ping from the on-premises server (10.50.50.6) to the PowerVS AIX (172.16.42.123).

[root@tamavsi01 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:00:06:11:ef:41 brd ff:ff:ff:ff:ff:ff
    inet 10.50.50.6/26 brd 10.50.50.63 scope global noprefixroute dynamic eth0
       valid_lft 235sec preferred_lft 235sec
    inet6 fe80::6ff:fe11:ef41/64 scope link 
       valid_lft forever preferred_lft forever
[root@tamavsi01 ~]# ping 172.16.42.123
PING 172.16.42.123 (172.16.42.123) 56(84) bytes of data.
64 bytes from 172.16.42.123: icmp_seq=1 ttl=241 time=143 ms
64 bytes from 172.16.42.123: icmp_seq=2 ttl=241 time=155 ms
64 bytes from 172.16.42.123: icmp_seq=3 ttl=241 time=146 ms
64 bytes from 172.16.42.123: icmp_seq=4 ttl=241 time=143 ms
^C
--- 172.16.42.123 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 143.775/147.450/155.514/4.778 ms
[root@tamavsi01 ~]#