OpenVPN Connect - Clients have it on when on premises
-
Hey,
Im trying to think a way of blocking openvpn connect for when the clients are on-premises, because it floods our pfsense logs and we get so many UNDEF connections.If they try a new connection from the wireless network, they can't connect, however, if they hibernate the laptop from home and come to the office with it on, it will stick to the server creating multiple entries for each one of them.
Perhaps a rule on lan dropping our external openvpn dns/ip as destination or wan rule dropping 1194 from our ISP IP?
It looks a bit silly, if someone has a better idea please let me know.Thanks,
Victor -
Why would these clients, connected to local Wifi, use you WAN IP, to connect 'back in' the network ? They are already 'in the network' ?
imho, OpenVPN should be used when trusted users, members of your local network, are outside, and need to reconnect to your network to use local resources ?
Or are these users mostly on the outside; and they have the OpenVPN app kick in on windows start and auto start the connection ? If so, disable this. They will remember to connect VPN when needed, as it is as phoning someone first when you need to talk to him. Hanging up the phone when done is also ... well ... like locking the door when you leave.
I guess auto reconnecting is biting you.edit : adding a firewall rule on the WAN => wrong : LAN, see below - that blocks connection from a LAN will also give your OpenVPN server some relieve.
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@Gertjan said in OpenVPN Connect - Clients have it on when on premises:
adding a firewall rule on the WAN that blocks connection from a LAN
I think you mean on the lan ;)
-
Actually is not the auto-connect, they just close the laptop with the vpn on, and they open the lid, it reconnects, if u are inside and try to establish a new connection, it wouldn't allow, its like keeping the connection state. but for each of them, it creates a big amount of UNDEF errors and generates logs, and when we need to actually troubleshoot something, its a pain.
So the rule would be:
block/drop destination: my.vpn.domain to the dest port : xxxx,
somehow it wouldnt get past the LAN and it will relief the ovpn interfaces, is that right?Thanks heaps,
Victor -
Something like (second rule) :
-
@Gertjan said in OpenVPN Connect - Clients have it on when on premises:
Why would these clients, connected to local Wifi, use you WAN IP, to connect 'back in' the network ? They are already 'in the network' ?
I have this set up on purpose. We are moving to a hotel model where users come in , pick a desk and VPN to get on the network.
DIA circuits at each office location. Technically they are "on" the network but its an Internet only VLAN.Granted the OP has a different use case in which simply creating a rule rejecting their WAN IP on port 1194 (or whatever port used for their ovpn implementation).
-
@michmoor said in OpenVPN Connect - Clients have it on when on premises:
DIA circuits at each office location
Hope they are faster then their home internet - and your internet connection into where they are vpn to.. Or you prob going to get complains its faster at home - I will just stay home ;) heheh
-
@johnpoz 1Gb dual internet More than enough. I think we are utilizing split-tunnel for this but not entirely sure.
When the bosses say its time to come back into the office at least 4 days a month its time. I'll never understand those decisions :( -
Yup. The rule blocking openvpn from the LAN side is what I have to do for the same reason. Without the rule, the VPN would connect and cause strange network connectivity issues. With the rule, the VPN doesn't work and it's easier to troubleshoot.
