/proc/interrupts and the like, interrupts are expressed as counters, i.e. "~170k interrupts serviced since last reboot". Without knowing how long the system has been up and running, such a counter is almost completely meaningless. What may be important is the number of interrupts per unit of time, or the interrupt rate.
On a VPN router, interrupts would be mostly generated by the NICs signaling that their input buffer (or e.g. the current DMA target for incoming packets of a particular flow, for more advanced server-grade NICs) is getting full. If a VPN router was unable to handle all its interrupts in time, you would probably start seeing packet loss on connections going through the VPN, or possibly failures and reconnections of the actual VPN tunnel(s).
A very simple NIC might just have an input buffer for X received packets and generate an interrupt whenever the buffer is nearly full, resulting in e.g. an interrupt for every (X-n) packets received. A more advanced NIC will probably be capable of DMA transfers on their own, so the processor can basically tell the NIC "here is a block of memory for you; put all incoming packets (for a particular source address/protocol/port combo) in there and don't bother me until either the memory block is getting full or something seems to be going wrong with the transfer", resulting in far fewer interrupts per unit of data transferred. So the exact type of the NICs you are using can have a large effect on the number of interrupts generated by a given VPN traffic workload.
If the processor is not capable of handling an interrupt in a timely manner, it might cause a situation where incoming packets are lost because the NIC has no place to store them. When the number of interrupts per unit of time is getting higher, you should see the percentage of CPU time used by system increase correspondingly.
When the interrupt rate becomes too great, you might actually see a decrease of CPU load, as when inbound packets are lost, there might be nothing to do but wait for the other end to retransmit the lost packets.
Depending on the specific VPN implementation you've chosen, the "CPU load average" value may or may not be an useful indicator of how hard the system is working, as much of the VPN-related processing may happen inside the kernel.