Pfblocker Permit Inbound Confusion
-
@blackops786187 So the goal here is just to allow one region using GEOIP for one port, and block the rest of the world, (and that is all that your PFSENSE is doing as there is just this one server behind it?) I wouldn't put an allow rule like that on the WAN, any/any - unless you have already configured the GEOIP to allow only 1194. Not needed anyway, the port is open. So just run the GEOIP deny rules for all the other regions and the 1194 rule that opens that port will be at the bottom for anything that doesn't match the denies. Unless you need other ports open for other things, you don't need allow rules that may be opening more than 1194.
-
Yes. I only want the UK IP's to access the VPN. I set up pfsense for openvpn and its ability to add additional security.
Like i said, the pfsense VM is on the LAN and is not my firewall device. Ive got a broadband modem/router which ive port forwarded 1194 to the pfsense VM so im not really opening up the WAN as pfsense isnt my firewall device and is just a VM on my network.
According to the pfblocker best practices, its not best to block the world but instead whitelist what needs to be allowed
-
@blackops786187 In a typical situation yes as the ports would normally be closed to unsolicited traffic by default, you would need to allow some IP or whatever, but the port is open per your bottom rule. Once something is open, there is no reason to allow, it is open already. You are trying to limit access before it gets to that bottom rule however so you need block rules, not allow rules.
Now if this is a point to point VPN and not a road warrior setup, and you were dealing with static IPs, you would only need to alter that bottom rule from SOURCE-ANY to whatever the other end's IP was and you would need no other rules for it. But as we are dealing with GEOIP, you need to block all the areas where there are no users who need to connect. Anyone not blocked, could get to that open port, and that is where your OPENVPN setup, (accounts-passwords, certificates...) come into play to prevent actual access.
Double natted I donno, does the VPN even work?
Before I changed ISPs last month I had one where I had to use their crap router, and had to put my PFSense in the DMZ and put everything other than TVs behind it. I had no desire to double nat. There's no point. If the ISP router is crap (and probably is compared to what you can do with PFSense) put it in bridge mode if the service allows such, and just use PFSense. You don't gain anything with double nat. Well, grief maybe.
-
Op where did you see that box you pasted in the pfSense interface?
On the rules tab it states this.
"Rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed).
This means that if block rules are used, it is important to pay attention to the rule order. Everything that isn't explicitly passed is blocked by default."Which is correct, the underlying PF processes rules in order, some rules may have the 'quick' flag which means it processes them as a higher priority rule, but a rule of thumb is rules higher in the UI are actioned first. So as the quote says rule order is important, typically certain rules get pushed to the top such as pfblockerng rules. But I think pfblockerng itself allows you to reconfigure that behaviour if you dont like it.
-
@Tzvia said in Pfblocker Permit Inbound Confusion:
Now if this is a point to point VPN and not a road warrior setup, and you were dealing with static IPs, you would only need to alter that bottom rule from SOURCE-ANY to whatever the other end's IP was and you would need no other rules for it. But as we are dealing with GEOIP, you need to block all the areas where there are no users who need to connect. Anyone not blocked, could get to that open port, and that is where your OPENVPN setup, (accounts-passwords, certificates...) come into play to prevent actual access.
Double natted I donno, does the VPN even work?
Before I changed ISPs last month I had one where I had to use their crap router, and had to put my PFSense in the DMZ and put everything other than TVs behind it. I had no desire to double nat. There's no point. If the ISP router is crap (and probably is compared to what you can do with PFSense) put it in bridge mode if the service allows such, and just use PFSense. You don't gain anything with double nat. Well, grief maybe.Create an Alias Permit then create custom firewall rules for your OVPN connection and ONLY enable your OVPN ports.
I do something similar with a sftp server sat in my DMZ to only allow hosts from the United Kingdom.
-
Hi Guys. Thanks for the replies. Ill try and answer everyones question. Im still a noob at networking and pfsense. There is no double NAT. This is my setup visualised as a diagram. DHCP assigns the pfsense VM an IP from my LAN subnet. There is no LAN interface on the pfsense VM. The only port ive forwaded on my BT router is 1194 to the pfsense VM. The VPN is working perfectly fine. Infact i did the same openvpn setup using the openvpn script which i used on a ubuntu VM and i thought i could replicate the setup on pfsense
The box i saw in pfsense is in the GEOIP settings. I only choose the UK country
-
Like i said, my goal is simply to filter out the Bad IP's using the deny rules as i said and then only allow ones which are from the UK to reach the openvpn daemon.
Would this work?. Ive made the europe GEOIP (UK Only) set as "Alias Native) and specified it as a source for the openvpn rule.
Traffic will be forwarded from the bt router to the pfsense firewall where it will be filtered by the deny rules (PFB_PRIx), and then only the UK IP's (which werent filtered out) will be allowed to talk to the openvpn daemon. I may be incorrect as im not that well versed in how port forwading works but im hoping i make some sense
-
There is a double NAT 192.168.0.254/24 is an RFC 1918 address.
Do yourself a big favour and try and get rid of it if you can.
Do it like I suggested and create an IP alias.
-
Hi, Can you explain how ive got a double NAT? I dont have a LAN interface on the VM. The pfsense VM is getting an IP from DHCP from my BT router putting it in the same network as the rest of my devices. Also i didnt set a LAN interface when i set it up
Like i said, im not the best with complex networking stuff so id appreciate any knowledge. Only way to learn :)
-
Sorry I missed the bit about no LAN interface.
Create an alias in pfblocker like my earlier screenshot otherwise you tie up the whole Europe GeoIP alias.
1 would be the alias you created.
2 would be the WAN address.
3 would be the port.
-
Not sure if ive done it correctly. This shoudl now filter all IP except for UK then apply the deny rules if they are bad IP's based on the feed?
Created an alias permit with only the UK selected
...................................................................................................
Created the rule (UK_Pass_GEOIP)
-
EDIT: Actually this may not work properly. Looking at the pfsense documentation, firewall rules are applied on a first match basis so in this case, if the IP is from the UK, the traffic will pass and the deny rules will be ignored as its based on a first match basis. Correct me if im wrong
Unless im missing something, why wouldn't this work. I mentioned this approach before.
If any IP matches the feeds in the deny rule, it will get blocked, then only the UK ip's (which werent on the bad feed list) will pass
-
@blackops786187 said in Pfblocker Permit Inbound Confusion:
If any IP matches the feeds in the deny rule, it will get blocked, then only the UK ip's (which werent on the bad feed list) will pass
That's correct as for the order. And then because of the default block rule, any other IP connecting to you will be dropped.
So in essence if you only cared about controlling inbound to the VPN port, you could skip the four inbound deny rules. Only UK is allowed in anyway by your bottom rule, and the rest is blocked by the default block rule "below that."
The outbound block rules would still affect/block outbound traffic (otherwise the connection could go out and the tracked state would allow the response).
Side note: you can also use Alias Native or other aliases as a NAT port redirection Source.
-
@teamits
Yes. My concern is limiting what reaches the openvpn daemon inbound.
In regards to your comment regarding removing the 4 deny rules, these rules are for Bad IP's. These feeds also have UK IP's in them so dont see how they are not needed as the UK geoip ruleset will allow all of the UK ip's and not filter out the bad ones
-
@blackops786187 said in Pfblocker Permit Inbound Confusion:
These feeds also have UK IP's in them
ah, if there is overlap then yes the block needs to be above the allow, sorry.
-
Maybe I am missing something, but once I read, quite a few posts up, that the OP didn't have a 'lan' on his PFSense VM, and that his internal network was in what the PFSense sees as WAN. So you setup the filtering of that port, allowing some regions and blocking other regions from that open port. But once someone outside authenticates, what do they see? Nothing. What is the point of the VPN? Is it to connect to it from the coffee shop down the street, encrypted, and back out through your internet? If the whole point was mentioned, I missed it...
I still think the PFSense needs to be where the home router is and not internal with no LAN. I mean, if the extra 'security' was really needed, why leave out all the devices at that location...
-
@Tzvia Its just used as a vpn endpoint to allow access to my LAN devices e.g my NAS drive securely and also , like you said, use public wifi securely without worrying about people snooping. Im not doing any firewalling my LAN devices with it. I could have easily used a ubuntu VM for setting this vpn up but wanted pfsense as i could configure firewall rules for VPN and using pfblocker for geoip whitlisting.
i wanted simply to lock down the open port i created on my bt router which is on the edge of my network and tighten my endpoint as much as possible
-
@blackops786187
But if I am reading it correctly, your LAN devices are, as far as PFSense is concerned, in the WAN. The VPN is not going to provide access to things in the WAN, from PFSense's perspective. It's for giving access to PFSense's LAN from the WAN. And you have nothing in the LAN, not even a ethernet port. No this is the wrong way to do things IMO. PFSense needs to be where your router is now. Your internal network needs to be on the LAN side. Router in bridge mode if the service permits it, OR worst case, PFSENSE in the router's DMZ with an internet IP on the WAN side, and all your internal items on the LAN side of PFSense.I have both OpenVPN and IPSEC setup and yes I use them while on public wireless, even my phone using OpenVPN. No split tunnel, everything through my VPN encrypted and going OUT to the internet via my network/PFSense. I feel a little safer in public and can get to my NAS and servers if I need to. I used to run PFSense in a ESXI VM using two standard virtual 'switches' and two nics, one in the lan and the other in wan but now I am back to using a physical box.
Have you done any tests? Can you see anything?
-
So your wanting to just have pfsense wan in your routers lan - and use that for vpn access to stuff in your lan?
Hmmm - you would for sure have to source nat vpn traffic so it looks like its coming from pfsense wan IP for that to have any chance to work.
What are you outbound nat settings, what are you using for the tunnel network?
Lets forget any blocking for a second - does the vpn work? And your just wanting to limit who can talk to the vpn port? Ie you want only UK IPs to talk to it?
I would validate the vpn actually is working how you have it setup before you go to lock it down.
-
@johnpoz lol. Of course i made sure the vpn is functional before i considered locking it down. I can access the devices on my LAN without issue. Cant remember the exact tunnel network but its in the 10.x.x.x range. I've got the UK geoip whitelist working by using the alias native settings and choosing only the UK countries. I added that alias to the source of the OpenVPN rule and ive confirmed its working as intended
