Block connection attemp from internal LANs

damianhl

Hello team!!

We have OpenVPN working well since many years ago in our PFSense, now my boss wants to block OpenVPN clients to connect to the PFsense, when they are inside the network.
For example, if a user has his notebook in his house, then should work, but if the user bring his notebook to the office, then he should not connect to OpenVPN.
The interface selected in the Open VPN settings, is the WAN, but still users can connect from inside
For testing, I added a firewall rule in LAN to block all comming from LAN, from an specific internal IP address (I need to test this just with one computer), and using the OpenVPN port (UDP 1194), but still this computer could connect.
Is this possible to block OpenVPN connections from inside?

Thanks in advance.
Regards,
Damián

Gertjan

@damianhl said in Block connection attemp from internal LANs:

Is this possible to block OpenVPN connections from inside?

I just did that.
If your WAN is a no-RFC1918, so the pfSense WAN is the IP you use to connect to when outside, then you good with a :

If your pfSese is behind another ISP router, your pfSense WAN isn't the IP visible from the outside.
That's my case.

So :

and you might ask: what is this WAN_IPv4 alias ?
Its my WAN IPv4

and pfsense.dyndns.org is set up here : Services > Dynamic DNS > Dynamic DNS Clients

damianhl

Hello Gertjan,

Thanks for your answer and sorry about the delay.
This did not work for me, I have created a LAN rule in the top of the list as your screenshot and applied the changes. Still can connect from a local computer.
In the rule I applied a source IP to test this with just one computer
Actually, we have 3 WANs in this PFSense, all directly connected to this (No another router behind), all no-RFC1918
The local LAN also is no-RFC1918, this is 150.0.0.0/16 (We adopted this). Is this the problem? How can I fix this?

Thanks in advance.
Regards,
Damián

Gertjan

@damianhl said in Block connection attemp from internal LANs:

Actually, we have 3 WANs in this PFSense

Ah, now the details are coming in.
Keep them coming ? A good answer depends on it.

@damianhl said in Block connection attemp from internal LANs:

The local LAN also is no-RFC1918, this is 150.0.0.0/16 (We adopted this)

What do you mean by that "we adopted this" ?
You own (== have the legal right !) to use "150.0.0.0/16" or you just 'picked' a /16 out of public space, and considered that you could use it without the wrath of the Internet Gods ? really ??

damianhl

@Gertjan

Thanks for your answer!
I dont need to hide information, in my first post I did not tell you all this because I didnt think this is relevant. Also, if I tell you all, the post will be tooooooo large.
With "We adopted this" I mean that when we first entered to this company, they already had this no-RFC1918 segment in his LAN and we could not change this still because of the service cut
Is there any additional information I could give you to understand the issue?

Thanks in advance.
Regards,
Damián

johnpoz

@damianhl that address space is china ips

inetnum:        150.0.0.0 - 150.0.255.255
netname:        CHINANET-SD
descr:          CHINANET SHANDONG PROVINCE NETWORK
descr:          China Telecom

As to a service cut - it should be only a few minutes tops.. As you switch over..

If you want to stop a client while they are on one of your local networks from talking to any IP on pfsense, be local IP or a public side IP be it rfc1918 or public. Then the rule shown by @Gertjan with destination of "this firewall" would include all IPs on pfsense.. But maybe your not using the standard 1194 port, or maybe you selected tcp when you use udp, etc.

Also if a client has already created the connection, then a state would of been made - if you then put in a block rule - that connection would still be allowed by the state. Unless you kill the state, or allow it to time out on its own - and then try to create a new connection which would be blocked by the rule.

damianhl

@johnpoz
You are right, maybe the issue was I tested this when the session was still active.
Now I tried again, and this machine could not connect again until I disabled this rule.
Thanks to both!

Just as a comment, few minutes is not enough to change the subnet and make it everything work, there are many servers, printers, etc, with fixed IPs

Thanks
Regards
Damián

Gertjan

@damianhl said in Block connection attemp from internal LANs:

This did not work for me, I have created a LAN rule in the top of the list as your screenshot and applied the changes. Still can connect from a local computer.

My first image again :

see the green part ?
That means that traffic matching the rule was found.
My PC, from my pfSense LAN was using my pfSense WAN IP with UDP traffic using port 1194.
UDP and port 1194 is 'default', you should chose what you use - see your OpenVPN server config for this.
If your firewall didn't show matches : that's because traffic had another destination, you were using another port, or using TCP instead of UDP.

Btw : The firewall (self) is an system alias macro that includes all IPs that pfSense is sung on all real and virtual NIC's, and localhost.

@damianhl said in Block connection attemp from internal LANs:

Actually, we have 3 WANs in this PFSense,

In that case, one more reason to use :

as the destination IP.

johnpoz

@damianhl said in Block connection attemp from internal LANs:

there are many servers, printers, etc, with fixed IPs

You don't have to move them all at once.. But this is normally why you would use dhcp, so you could easy migrate 100 if not 1000s of devices to a new IP scheme.

But you can for sure just move one at a time if you so desired.. The outage on any specific device would be very short - the time it takes to come up on its new IP.

Such a scenario is one of the scenarios where it makes sense to run multiple layer 3 on the same network for a time, ie transition.

If me, I would as your migrating devices to a better network IP range change them to dhcp with a reservation so say server 1 always gets IP X, server 2 always gets IP Y, etc..

I would change your network to your new IP range, then put a vip on pfsense for its old 150 address, etc. Then slowly move over the devices to dhcp on the new network assigning the IP address you want for each device. You would just need to change the port forwards you currently have as you do.