Restrict access from a public IP range for a specific user

johnpoz

@mroushdy Why don't you just have the client update a ddns entry, and whitelist that fqdn to be able to use the vpn?

Then it doesn't matter when his IP changes.

Also whitelisting IPs that have to AUTH to a secure vpn seems a bit over the top.. I mean I could see if it was just open access to a port..

But doesn't the user need to have a cert and a username and password to auth to the vpn anyway.. Having to also allow only 1 specific IP seems over zealous..

Then just lock down your vpn to your country - if your worried about Russian h@ck0rs ;)

netblues

@mroushdy You can run ips/ids on pfsense, which I guess you are using as a vpn access server

netblues

@johnpoz This has been suggested, however ddns entries tend not to update very fast, especially if you have remote workers and you can't wait for long for ip name propagation to occur.

johnpoz

@netblues what would be the point of the ids/ips? Makes no sense in a vpn scenario to be honest..

As you mentioned the tls key prevents rando attempts to the vpn port anyway. And authing to a vpn is more then secure enough to validate it is the user that is authing. They need a CERT, that only the company issued and a username and password.

johnpoz

@netblues said in Restrict access from a public IP range for a specific user:

ddns entries tend not to update very fast

Not sure where you got that idea.. Its not like the IP is changing every freaking minute... Every time the IP changes it would be updated. The alias that looks to see what this fqdn is would check every 5 minutes.

The whole point of ddns is changing IPs - ttls could be as short as couple of minutes.

To be honest the whitelisting of an IP for a vpn connection screams your tinfoil hat is too freaking tight in the first place.

mroushdy

@johnpoz I already agree with you that a cert-based auth with a password is quite enough, but the security officer is more masticulous, I even suggested whitelisting our country and that's it.. I may consider DDNS.

Thanks,

netblues

@johnpoz I stand corrected
https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html
300 seconds .
However if you stumble upon minimum ttl dns server setting, set to 86400, then you won't get it that fast.

Always something to worry about.

I wouldn't do it large scale by no means.

johnpoz

@mroushdy said in Restrict access from a public IP range for a specific user:

but the security officer is more masticulous

I would use a different word ;) hehehe to describe such nonsense..

netblues

@mroushdy said in Restrict access from a public IP range for a specific user:

@johnpoz I already agree with you that a cert-based auth with a password is quite enough, but the security officer is more masticulous, I even suggested whitelisting our country and that's it.. I may consider DDNS.

Thanks,

So we suppose you have already invested into zerotrust approach, with endpoint protection et al.

Right?
Give your security "expert" a few more things to improve his attitude. :)

johnpoz

@netblues said in Restrict access from a public IP range for a specific user:

However if you stumble upon minimum ttl dns server setting,

And where would you see that - the user setting up the ddns would be able to pick that - cloudflare ddns allows for a 1 min ttl.

Now your thinking DNS the company is using to check this ddns that server is overwriting the ttls of records with a min 1 day - wtf would they be using such a dns server for that doesn't honor the TTL of a record?

I can see limiting the VPN access to a specific country of origin - really just to lower the spam to the vpn log ;)

Mar 20 01:08:36 	openvpn 	30029 	TLS Error: tls-crypt unwrapping failed from [AF_INET]162.142.125.138:38028

With a proper setup vpn - if the client doesn't use the correct TLS key - they can not even start to auth to the vpn server.

netblues

@johnpoz I'm just saying that there are other intermediates that need to be checked upon, and they might also change their minds without telling anyone too.

johnpoz

@netblues Well guess the client has to call in then - just like they are doing now when their IP changes every few days ;)

edit: Just out of curiosity what are your vpn settings? Sure and the hell hope your just not using shared key?

So lets think about what would be required for some unwanted user to auth to a your vpn. They have to have the TLS key. They have to have a cert issued by your CA (which could have a password on it). They need a user name and password.

And if your tin foil hat is really tight - setup MFA for authing to the vpn as well.

Trying to use the IP of the client on top of all of that seems just pointless, especially when you have clients that have IPs that change on a regular basis. What if this client internet is out and they have to go to the local starbucks, or hotspot off their phone cell connection to vpn into work? They now also have to call someone to get them to update the IP on the firewall that can talk to the vpn server?

noplan

@johnpoz

OH yeah totally agree on this one
Had a couple of IT managers only want to allow static ipv4 from their homeOffice users and forced them to pay the upgrade (and that's floppy expensive here where I live) for that static IP and we are Not talking about gov contractors

Was a hard piece of work to finally talk some sense into

Multi factor Auth on openVPN was the key for success

Np