3 Problems for a newby using pfsense: NAT, Internal Access, and Internet Access
-
Afternoon everyone, I'll start with an apology for the length of the post!
I've just migrated from raqcop to pfsense, and I currently have three problems:LAN is 192.168.10.1/24
OPT1 is 192.168.12.1/24 (known as Orange)1) NAT from OPT1 to two LAN addresses
I've got an incoming rule that directs web traffic to the web server on opt 1, and that is forwarding and working.
My web server is running a reverse proxy that forwards traffic to two separate machines on my LAN depending on the address, e.g.
emby1.mydomain.com (URL rewrite to 192.168.10.101)
emby2.mydomain.com (URL rewrite to 192.168.10.102)
Both machines are running on the same port and ideally, I'd like to keep it that, can I create a NAT rule that allows traffic from OPT1 to two separate address on the LAN?2) I've got no internet access from OPT1: I've created a rule for OPT1: I don't want to allow opt to any if I can help it.
3) Unable to access my network internally via its full url: e.g. blog.mydomian.com or emby.mydomain.com
When putting the web address in, I was being redirected to the pfsense menu, So I enable the option:
"Disable webConfigurator redirect rule"Now I get nothing, this is causing me problems with some of my media systems that use the global URL. (like laptops and mobiles)
I would appreciate any help that anyone would happy to give me.
I've attached a copy of my OrangeLan Rules, and my NAT rules.
![Orange LAN Outbound.PNG](/public/imported_attachments/1/Orange LAN Outbound.PNG)
![Orange LAN Outbound.PNG_thumb](/public/imported_attachments/1/Orange LAN Outbound.PNG_thumb)
![Nat Outbound.PNG](/public/imported_attachments/1/Nat Outbound.PNG)
![Nat Outbound.PNG_thumb](/public/imported_attachments/1/Nat Outbound.PNG_thumb)
![NAT Port forward.PNG](/public/imported_attachments/1/NAT Port forward.PNG)
![NAT Port forward.PNG_thumb](/public/imported_attachments/1/NAT Port forward.PNG_thumb) -
Can anyone help at all please?
-
Setting Pure NAT for NAT reflection mode sorted out the issue of not being able to access the external address internally. That is one problem (3) sorted.
-
It really feels like I'm talking to myself here. lol
Using this post below, I managed to get the DMZ talking to the outside world, but blocked from the LAN or firewall.
https://forum.pfsense.org/index.php?topic=122048.0
-
-
NAT from OPT1 to two LAN addresses
there is no local NAT between interfaces. Just rules. -
I've got no internet access from OPT1: I've created a rule for OPT1
Surely with that ruleset ;-)
Destination WAN address is exactly that: the WAN address of your pfSense. I doubt you want to sent traffic there. Same with WAN net which defines the transit network between your WAN IF and your ISP.
Here's how lots of us do it:
Since rules are processed top to bottom with "first match wins" you have to take care of the rules order.
You may want to create an alias for RFC1918 networks first.
Add a block rule to this alias preventing OPT1 to anything local (RFC1918). In your case you might want to create an allow rule to your LAN hosts on top of this block rule as well.
Then create an allow * rule for everything not local (aka internet).
You might need rules for DNS, SNTP, what-have-you as well.- Unable to access my network internally via its full url: e.g. blog.mydomian.com or emby.mydomain.com
You can do that with NAT reflections or you setup a split-DNS where your local DNS server points the URLs in question to the local IPs. Split-DNS is the more mature way of doing it while reflections are considered a hack by some. At least the traffic has to travers your router in and out to reach its destination which is avoided with split DNS.
-
-
Thanks Chris,
I've attached my DMZ rules and my
DMZ Port forwarding. Any help on this would be appreciated.So far as i can see, everything is working now except the split url rewrite:
emby.mydomain.com to one LAN IP
emby2.mydomain.com to Another.Should I create a rule that allows the port from my reverse proxy server to each of the LAN servers?
![DMZ Rules.PNG](/public/imported_attachments/1/DMZ Rules.PNG)
![DMZ Rules.PNG_thumb](/public/imported_attachments/1/DMZ Rules.PNG_thumb)
![DMZ Port forwarding.PNG](/public/imported_attachments/1/DMZ Port forwarding.PNG)
![DMZ Port forwarding.PNG_thumb](/public/imported_attachments/1/DMZ Port forwarding.PNG_thumb) -
It's crazy how just talking it out sometimes helps. These are the rules I have setup now, and I'm now able to access both my servers from different URLs running on the same port:
Is there any way I should improve the order or setup of these rules at all?
!!EDIT!! DMZ PORT FORWARDING FROM ABOVE:
I've removed all port forwarding with the exception of port 80. I assume this is much more secure?
![DMZ Rules.PNG](/public/imported_attachments/1/DMZ Rules.PNG)
![DMZ Rules.PNG_thumb](/public/imported_attachments/1/DMZ Rules.PNG_thumb) -
I'd prefer to have the DNS rule on top of the others, basically everything to the firewall first. But that's just me.
The rest seems fine. You actually don't need the "deny DMZ net to this Firewall rule" because everything that's not allowed will be blocked automatically. Think of a hidden "block all" rule at the bottom of your rule set.It's crazy how just talking it out sometimes helps.
Not at all, that's a known fact. Sometimes part of good teamwork.
And I prefer that you did it yourself over I just told you. You gained a lot now.PS: That's all a shrink doctor usually does: ask a question and let you talk about it. ;D
-
Thanks for your help Chris,
Does that mean I also don't need the deny DMZ to LAN?
One more question if you don't mind, rather than allowing HTTP and https to all, can I just allow it to the internet?
I've also noticed that although my DMZ machines are now showing as connected on Teamviewer, I'm unable to connect to them, do i need to open anything else inbound? -
Does that mean I also don't need the deny DMZ to LAN?
You don't need it but sometimes it's easier to understand a ruleset if such a deny rule is visibly there.
(instead of having to remember the "invisible" deny all rule at the bottom)rather than allowing HTTP and https to all, can I just allow it to the internet?
Define "the internet" in CIDR notation. ;)
… machines are now showing as connected on Teamviewer, I'm unable to connect to them, do i need to open anything else inbound?
Are those windows machines? If so then the Windows firewall needs adjustments. It usually blocks non-local (same subnet) traffic.
-
Thanks Chris. I've changed the order of the rules, I think I'm going to need to look at them again as I cannot get to my backup emby server now. I assume I've screwed the ordering somehow.
rather than allowing HTTP and https to all, can I just allow it to the internet?
Define "the internet" in CIDR notation. ;)
pmsl., Let me rephrase that, can I allow http(s) through the gateway rather than to all interfaces?
… machines are now showing as connected on Teamviewer, I'm unable to connect to them, do i need to open anything else inbound?
Are those windows machines? If so then the Windows firewall needs adjustments. It usually blocks non-local (same subnet) traffic.
These were VM's that were migrated from HyperV, if they are put onto my LAN they connect without a problem.
-
Define "the internet" in CIDR notation. ;)
pmsl., Let me rephrase that, can I allow http(s) through the gateway rather than to all interfaces?
Sure, it's just a matter of rule arrangement.
Gimme your educated guess first, remember what can be expressed in CIDR notation easily.These were VM's that were migrated from HyperV, if they are put onto my LAN they connect without a problem.
Again, which OS is twisting bits there?
-
Thanks. Logic says to me that the source should be DMZ and the destination should be WAN net.
Sorry the VM's are server 2012 / 2016 migrated from HyperV to Unraid.
-
Server2012/2016 IS a Windows machine so it WILL block traffic from other than its own subnet by default. Adjust the Windows firewalls.
Logic says to me that the source should be DMZ and the destination should be WAN net.
Same with WAN net which defines the transit network between your WAN IF and your ISP.
I still doubt you want traffic TO the transit network. TO is not THROUGH. That is not your destination.
Think out of the box:
-block traffic to 80 & 443 with destination RFC1918 (aka everything local)
-allow traffic to 80 & 443 with destination * AFTERWARDS, so both rules together make it all but local.That's why rule order is important.
-
Morning Chris, I'm so lost now. :'(
As a guess though, I think I need to change the order of the rules you mention?I've got two other questions when we've sorted this too!
Hardware:
Currently running on:
i3-6100 @3.70Ghz
4Gb RAM
250Gb SSD
3* Intel NIC Cards (single port), 1*Onboard NIC. (one Intel Nic card currently not used)Squid off: (Direct ISP) 180 - 210Mbps
Squid on: (Direct ISP) 5 - 12Mbps
Squid off: (VPN On) 40 - 60Mbps
Squid on: (VPN On) often unable to perform a speed test.Any idea why this might be?
If I create say three SSID's on my Access Point and tag those with say VLAN 20,30,40 can I route the traffic from those through separate VPN connections the firewall is handling? i.e. through different providers? I assume this would be just a case of adding the tags to the interfaces (Ovpn2) and then copying the outbound NAT rules from the default connection, is that correct, or is this subject for another topic?
I really appreciate your help!
Karl
-
Slow, one problem at a time. Don't jump to other stuff before the first is solved (and understood).
As a guess though, I think I need to change the order of the rules you mention?
What?
You described your DMZ rule as:Logic says … the destination should be WAN net.
and that destination is wrong. WAN net is the transit network between your WAN interface and your provider's gateway. Nothing more, especially not "the internet".I described your DMZ rules in words. Can you understand that or do you need the rules written?
Squid off: (Direct ISP) 180 - 210Mbps
Squid on: (Direct ISP) 5 - 12Mbps
Squid off: (VPN On) 40 - 60Mbps
Squid on: (VPN On) often unable to perform a speed test.Any idea why this might be?
No idea.
… three SSID's ... VLANs ... through separate VPN connections ... adding the tags to the interfaces (Ovpn2) ...
... or is this subject for another topic?Definitely worth another topic.
-
Ok, so I've spent the last couple of lunchtimes trying to get my head around subnetting and understanding the "/24" part at the end of an IP address and I've got my head around that now (I think.)
If I change the DMZ outbound rule, and set the destination to "any" the DMZ machines can access the internet. As I have a rule that blocks the DMZ from LAN I believe I could leave it like that and everything would work ok.
I don't really want to set a rule that allows all, then another to block DMZ to LAN; I would much rather set a rule that allows DMZ to access the internet only.
Below are the DMZ rules and NAT config.
![NAT Config.PNG_thumb](/public/imported_attachments/1/NAT Config.PNG_thumb)
![NAT Config.PNG](/public/imported_attachments/1/NAT Config.PNG)
![DMZ Rules.PNG_thumb](/public/imported_attachments/1/DMZ Rules.PNG_thumb)
![DMZ Rules.PNG](/public/imported_attachments/1/DMZ Rules.PNG) -
I've spent this evening reading and re-reading your post, then having a play with the rules. I think I've got this now, please correct me if I wrong.
if I put the rules in this order with the following settings.
- deny DMZ to LAN first it will block it if anything tries to access the LAN from the DMZ.
- allow HTTPS and HTTP to all destinations and set the gateway to either default to one of my open VPN clients, it will have access to the internet but as it is processed AFTER the deny rule, won't affect anything going to the LAN
Enable "Block private networks and loopback addresses" and "Block bogon networks" on all interfaces except LAN.
Thanks.
Karl
-
I don't really want to set a rule that allows all, then another to block DMZ to LAN; I would much rather set a rule that allows DMZ to access the internet only.
Problem is that you cannot define "the internet" in an alias or CIDR notation.
You could make a single rule with a negotiation "allow all but LAN" with the "NOT" checkbox. Deny LAN will finally catch with the hidden/invisible "block everything else" rule at the bottom of your ruleset. Problem is that such a rule implies something that is not expressively written and thus makes it hard to understand what you were doing in future reviews/changes. With two separate rules it's obvious and visible.I think I've got this now, please correct me if I wrong.
Nothing to correct, well done! And I mean really well done. You learned a lot, didn't you!
Enable "Block private networks and loopback addresses" and "Block bogon networks" on all interfaces except LAN.
That's usually not really needed and if you use it then that'll be on WAN at best. The "Bogon" part can come handy there but better ISP filter that anyways. Except for edge-cases you will not have traffic from private IPs to your WAN anyways.
On local interfaces the "Block private networks" can do more harm than good. All local interfaces usually belong to private networks, aka RFC1918.