(internal) Packet capture in a google cloud VPC network

google-cloud-platformpcap

I have a VPC network set up in google cloud with a few instances running. One of these instances serves as a VPN machine, allowing me to interact with the instances from the internet.

I want to capture traffic:

From the internet to the VPC network. For this I simply use tcpdump on the vpn machine.
Internally, i.e. packets between the instances. And that I don't know how to do. I cannot rely on my instances (using tcpdump directly in them isn't an option in my case). Instead, because in VPCs there is no "real" network layer 2 as it is virtualized, I was hoping that it would be possible to somehow tap into the cloud router and capture all packets from there, but it doesn't seem to be possible. Or is it?

Does anybody have an idea on what I could do here? Would be much appreciated. Thanks!

Best Answer

Assuming you are using a Debian image from Google you can install and use tcpdump to capture traffic.

$ sudo apt update
$ sudo apt install -y tcpdump
$ sudo tcpdump -i eth0

Related Solutions

Google Cloud VPC – DNS Not Shared in Network Peering?

To a degree you have already answered your own question. You are right, as per the documentation you reference the internal DNS scheme is not available across VPC peering on GCP today.

You have three options.

Use hosts files, as you have been. This is simple to set up, but can be complex to maintain as your environment grows, though you could look to configuration management tools to help there - e.g. Ansible - to automatically distribute and maintain updates.
You could deploy a new DNS zone on Google Cloud DNS. More details of that service here: Cloud DNS Overview Though this service is for public zones only at this time, so you would need to register a domain or use one already owned. And as a public zone the names would be resolvable on the internet, which may or may not be desirable. You could also use an external public DNS provider.
Deploy your own DNS servers. You could setup BIND or similar on virtual machines to act as a DNS server. You would need to update the DNS settings on the VMs to use these new servers and I would suggest deploying at least two, for example one in each of your VPCs, for resilience. The main advantage would be the zone can be private, so you would not need to buy a domain name or expose the records on the internet. Of course you would need to maintain the DNS servers, which may or may not be desirable. You could also run remote private DNS servers, for example over a VPN, but I wouldn't recommend that per se, as then you create a hard dependency on the VPN connection.

Worth adding that both AWS and Azure support private zones as part of their own DNS services, so it's not inconceivable that Google will add support for similar in the future.

Hope that helps.

Google Cloud VPN: multiple tunnels from behind NAT

I managed to run multiple tunnels from behind a single public IP address using one Cloud VPN per device behind NAT.

| net1 | --- | router1 | --- \
                               \  priv        onprem       pub   
| net2 | --- | router2 | ----  | ---- | main_router NAT | ----------- >
                               /
| netN | --- | routerN | --- / 

       /--> | Cloud VPN Gateway for router1 |
----> |--   | Cloud VPN Gateway for router2 |
       \--  | Cloud VPN Gateway for routerN |

Here is how:

each device behind NAT initiating the IPSec tunnel (router1, router2 ... on the schema) should advertise its authentication id as the public IP of the NAT router (main_router NAT), not its private address.
NAT router must allow ports 500 and 4500 from the Google Cloud VPN gateways.

And now the most important part: on the main NAT router set D-NAT rules that direct traffic from each Cloud VPN Gateway to the private IP of the device that established a specific tunnel. In other words, one have to set N DNAT rules for N tunnels. This way each initial IKE conversation from Cloud VPN can be delivered to the appropriate routerN. Each subsequent traffic is caputer under ESTABLISHED,RELATED stanzas.

I looked at rules counts, etc. on my routers and it works as I described above. The IPSec tunnel is a split tunnel, which means that the Cloud VPN Gateway will try to contact the address specified in the Gateway configuration -- which in our case is always the same public IP address of the main_router NAT. Our main_router NAT must forward packets (based on the source IP address) from specific Gateways to specific internal routers.

Best Answer

Related Solutions

Google Cloud VPC – DNS Not Shared in Network Peering?

Google Cloud VPN: multiple tunnels from behind NAT

Related Topic