Any advantage in using a dedicated static IP for a VPN tunnel (different than the main WAN IP)?

[HCHTech]

I so rarely come across someone with more than one Static IP on their internet service, I'm just curious. If I have a block of 5 statics, is there any advantage to using a different Static for a full-time VPN tunnel than I use for the main internet access?

 

[phaZed]

To be corrected, but I don't think so... not beyond making things compartmentalized and perhaps easier on the Firewall/Config for the network side of things.

I suppose it would be good to be able to hand out the VPN IP and not have to worry about revealing the "company's main IP" - but that'll be public if anyone wants it, really.

It'd be "easier" to be able to configure the IP's firewall rules per IP - Strict for the Office IP, and then only allow VPN traffic on the VPN IP, etc.

If one IP is getting DDOSed, could they just switch to a backup IP? I'm trying here! In a world of NAT, multiple IP's has certainly been less of a thing.

 

[Sky-Knight]

I consider VPN to be "normal internet access" and only call for dedicated addresses when there's some hosted service to separate. SMTP in particular needs specially handled.

So no, P2S and S2S tunnels all use the primary static address along with general Internet egress.

There is no protecting an Internet pipe going anywhere, to anything from DDOS. IP separation changes nothing, if traffic is on the path the path will eventually run out of room.

SASE / ZTNA use means no more VPN, no more exposed services operating in the field at all, all exposed services in the Datacenter operating as SaaS or IaaS where we have more resources to do stuff on this level. This is the "future". And by that I mean this is "now".

 

[NETWizz]

I so rarely come across someone with more than one Static IP on their internet service, I'm just curious. If I have a block of 5 statics, is there any advantage to using a different Static for a full-time VPN tunnel than I use for the main internet access?

Yes there is usually a big advantage (learn from my mistake)... using one (1) of your 5 static IPs for all your tunnels, but nobody tells you this until you find out the hard way years later. Speaking from personal experience...

It is mostly dependent upon the ISP. I am someone who manages a network, which has a public /29 and a /24. The way this works is that the ISP advertises those subnets at your firewall(s), so you can pretty much do whatever you want with them except they are typically not the actual IP that you use to peer to your ISP.

For example, if a provider gives you 1.2.3.2/30 or /31 as your IP, you would peer to 1.2.3.1 and 1.2.3.3 respectively, which in the simplest of terms is making a default-route 0.0.0.0/0 via the ISP's IP as the next hop. In more complicated networks, this peering generally, usually involves BGP... but what it basically does is let you have multiple datacenters and you can dynamically claim your /29 or /24 or part there-of depending upon how the protocol is configured by the ISP. Either way BGP Is way out of scope here...

Speaking to your question, the problem comes with say upgrading your Internet service even with the same ISP or moving your datacenter. They typically ALWAYS assign you another static despite your vehemently voiced objections (looking at you, AT&T)... predominantly because their system (any ISP not just AT&T) does NOT allow them a way to keep the same peering IP/subnet with the installation of a new service unless you can shutdown the existing, then leave it long enough for the automated scripts to cleanup/re-claim it, then put in an order asking for that specific IP again and waiting maybe 30 days for provisioning.

In short, the static IP you peer to the ISP with is not necessarily yours to keep if you make any changes to your service/circuit. In contrast, the subnets advertised at your firewall can generally, readily be simply updated in the ISP's routing tables to point at your firewall via your new peer IP. In short, you generally keep those.


==> In short, contact your ISP from the outset.


Below, none of these that say "IPSec Outside IP" existed before I figured this out AFTER it became a problem and I had to move a datacenter:

I had to work with an external vendor, a colocation facility, a laboratory management system company and their University support, some hospital IT staff, a couple of Government Agencies, and a Cradlepoint NetCloud administrator to get this sorted out for them to change the IP address they are peering with..

What you are looking at "IPSec Outside IP" here is the Address Object for one (1) of my Public IPs. It is assigned to loopback.4 and works fine for ALL of my tunnels on this VSYS (virtual firewall) and Virtual Router. I have both static and dynamic tunnels, too... You shouldn't need a separate IP for each tunnel from your 5 IPs (your /29).

 

[Sky-Knight]

I've seen the above! But it only happens with COX if you have more than 3 static addresses.

I hadn't considered that specific use case, but yes you're right. The ranges delivered this way can simply be pointed at a new "local" address on the router and are much more portable.

Which in the case of IPSec is a big deal because it saves you having to reconfigure all those tunnels!

 

[YeOldeStonecat]

In the...what I'll call..."older days" of my clients having on prem servers...especially larger clients that had multiple servers, such as on prem Exchange, and a Terminal Server (RDG later), dedicated VPN appliance like a Juniper, old fashioned security cameras that required port forwarding to a DVR/NVR....yeah multiple WAN IPs were good and useful. I could separate things, keep things cleaner on the firewall.

But these days...no on prem servers, well, that's thankfully wiped out the need for VPNs. For "just a VPN"....I'd not strive for having it on one of the additional IP aliases.

We still have a full block at our office...and used to use a lot of 'em. Now..just the first IP gets used for our internet access.