Overview

There are multiple use cases where it is desirable for virtual server instances (VSIs) in Power Virtual Server to have egress access to the internet. A common use case is obtaining software packages and updates. One way to enable egress is to add the VSI to a public VLAN. A major downside of this approach is that this also allows internet ingress on SSH, HTTPs, and many IBM i administrative ports. This exposes these ports to internet login attempts. A common way to enable egress while maintaining private networking, and have complete control of internet ingress is to use a Classic Gateway Appliance and route the internet traffic through it. This requires gateway appliance administrator skills and a bare metal gateway be more than you need to simply satisfy an internet egress requirement.

This article uses simpler techniques for internet egress and makes use of a VSI in Virtual Private Cloud (VPC) which only requires some Linux administration skills instead of specialized gateway appliance skills.

Egress through a public gateway in VPC with IP forwarding

One simple way to create internet egress for Power virtual server instances (VSI) is to use a VPC VSI with IP forwarding enabled. Using this method, internet bound traffic from the Power VSI is routed to a VPC VSI which uses IP forwarding to allow internet egress through the VPC subnet’s public gateway. The architecture looks like this:

To implement this architecture:

1. Create a VPC with a subnet that has a public gateway. Attach the VPC and your Power Virtual Server workspace together with a Transit gateway.
2. Create a VSI in the subnet and the set VSI’s network interface is set to “Allow IP spoofing”. IP spoofing can also be enabled after the creation of the VSI. Here is a view of a VSI’s virtual network interface showing the “Allow IP spoofing” toggle enabled. 
   
   
   
3. Ensure that the subnet access control list and the security group(s) in use by the VSI’s network interface allow traffic with the PowerVS network CIDR on the desired protocols and ports such as TCP on ports 80 and 443.
4. Create a routing table in the VPC with the Transit gateway traffic source enabled and the “Advertise to” option enabled:
   
5. Add two routes to the routing table. One route is for the local VPC network with Action set to Delegate. This keeps the local VPC traffic within the VPC. The second route which is for internet traffic should be for destination 0.0.0.0/0 with the next hop being the VSI’s IP address. This route should be set to “Advertise: On”. Setting Advertise to On for this route advertises the route to the transit gateway. This makes the transit gateway route all internet bound traffic to the VSI.
   
   
6. Enable IP forwarding inside the VPC VSI. To enable IP forwarding on Red Hat Enterprise Linux 9 or CentOS 9:

   Run "echo 1 > /proc/sys/net/ipv4/ip_forward"
   To have IP forwarding enabled at system start, create a file named /etc/sysctl.d/90-enable-ip-forwarding.conf with contents: net.ipv4.ip_forward = 1 .

Internet bound traffic from the Power VSIs should now egress through the VPC VSI.

Egress through a VPC floating IP or public gateway with Network Address Translation

Rather than simply forwarding packets, the VSI can use network address translation (NAT) and firewall rules to act as an edge proxy firewall. In this architecture the VPC has two subnets, one that is outward facing to the internet and another which is inside facing and does not have a public gateway. The VSI has a network interface in each subnet and uses NAT and IP forwarding to direct internet traffic out through a floating IP address or the subnet’s public gateway. This use case is also covered in the VPC documentation. This technique could have higher bandwidth since two network interfaces are being used instead of one, and opens up the possibility using the VSI’s firewall to have finer control on internet traffic.

This architecture is like the previous one, but some configuration differences of note are:

• The VSI should have two network interfaces. One in each subnet. They should both have IP spoofing enabled. The interface in the “outside” network should be the primary interface (eth0) to make later routing changes easier.
• The VPC routing table should have a route added for the inside network (10.17.19.0/24) with action delegate.
• For internet egress through the outside network, a floating IP address can be attached to the VSI’s network interface or a public gateway can be enabled on the subnet.

Like the previous architecture, IP forwarding needs to be enabled in the VSI. The configuration uses firewalld set up NAT and the NetworkManager CLI to set a static route:

Set up NAT in firewalld

1. Start firewalld and enable it to start on system start
   systemctl start firewalld
   systemctl enable firewalld.service
2. Enable NAT
   firewall-cmd --direct --add-rule ipv4 nat POSTROUTING 0 -o eth0 -j MASQUERADE
   firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i eth1 -o eth0 -j ACCEPT
   firewall-cmd --direct --add-rule ipv4 filter FORWARD 0 -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
3. Save the firewalld configuration
   firewall-cmd --runtime-to-permanent

Set up static route for inside traffic

The outside/internet facing network adapter is eth0 so the VSI’s default route will automatically work for internet bound traffic. Additional routes are required for inside bound traffic going out the eth1 interface to use the inside network’s gateway. The NetworkManager CLI “nmcli” is used to set static routes.

First run “nmcli” to find the name of the connection that eth1 is using. In the following output, eth1 is using a connection named “Wired connection 1”:

$ nmcli
eth0: connected to System eth0
…
eth1: connected to Wired connection 1
"Red Hat Virtio"
ethernet (virtio_net), 02:00:04:86:B6:A9, hw, mtu 1500
inet4 10.17.19.7/24

Add a static route for every network that is using the VSI for egress. In this example, the 10.113.113.0/24 network from PowerVS is being added with the “inside” network’s gateway as the next hop:

nmcli connection modify "Wired connection 1" +ipv4.routes "10.113.113.0/24 10.17.19.1"

Bring the connection up to apply the configured route:

nmcli connection up "Wired connection 1"

Verify the route is in the routing table:

$ ip route
default via 10.17.23.1 dev eth0
default via 10.17.23.1 dev eth0 proto dhcp src 10.17.23.4 metric 100
10.17.19.0/24 dev eth1 proto kernel scope link src 10.17.19.7 metric 101
10.17.23.0/24 dev eth0 proto kernel scope link src 10.17.23.4 metric 100
10.113.113.0/24 via 10.17.19.1 dev eth1 proto static metric 101

Internet bound traffic from the Power VSIs should now egress through the VPC VSI.

Conclusion

Using these techniques you can quickly set up internet egress for Power VSIs without gateway appliance administration skills and without exposing your VSIs to internet ingress traffic.