Block access to wan address from lan net
-
Hi all,
I can't solve this problem, clients in lan network shouldn't access to wan address of pfsense, but they can! I have flagged "Block private networks and loopback addresses" on wan interface but it seems doesn't work. This is my config:WAN address: static public ip xx.xxx.xxx.xx
LAN address: 192.168.0.1/16
NAT outbound: source 192.168.0.0/16 , nat address: wan addressIf a client from LAN net goes to xx.xxx.xxx.xx wan ip address, it accesses the weblogin of pfsense, the system log says that xx.xxx.xxx.xx is trying to access to itself because of nat outbound rule above.
How can i fix this?
-
Generally you shouldn't permit GUI access on WAN address, but only from LAN.
If you have it open though, but want block access from LAN you need a block rule on LAN interface.
This one
@ninoalcamo:I have flagged "Block private networks and loopback addresses" on wan interface but it seems doesn't work.
only blocks access coming in the WAN interface.
So add a block rule to the top of the LAN interface rule-set, set it to the GUI port and select WAN address at destination. This should do what you intend.
-
I have already added a rule like this in lan rules section:
block,ipv4,any,any,wan address
but clients in lan can still able to access web gui on wan address
-
post up your rules please. Screenshot! if you add that rule below the default any any rule it would never even be seen.
Rules are evaluated top down, first rule to match wins, rest of rules are not even looked at.
So if you want to block from accessing gui, make sure it above any rules that would allow the access.
Also its prob best to use the built in firewall alias. Because if you block access only to the wan address, they could just hit say a opt interface address to get to it, etc.
So for example - see my guest network rules.
I allow ping to pfsense wan guest interface both ipv4 and ipv6
I then reject and log such attempts all access to ANY firewall IP on any interface, wan, lan, dmz, every other firewall IP.I then have a not rule (the !) that says hey if your not going to a rfc1918 address.. So like internet then allow. I then allow access to any ipv6 address as long as its not one of my Ipv6 networks that include a /48 I have an the other /64 I have from HE, etc.
So for example if going to say 192.168.2.100 on tcp port 80 you walk down the rules.. No match, no match.. no match all the way down because 192.168.2.100 is in my rfc1918 alias so no match, and not ipv6 so no match, so it would hit the default block rule that is not shown.
Now lets say it was a udp dns query on port 53 to 8.8.8.8 .. No match, no match nomatch.. Hey that dest is NOT a rfc1918 address, and yeah its IPV4 - so allow! Or tcp on https to www.google.com (not a rfc1918 address)
Does that make it bit more clear?
BTW.. Why are you using LAN address: 192.168.0.1/16… That is HUGE freaking network.. Do you have some 65,000 clients on your lan? If not then why such a big network mask?? Pretty much is a guarantee that your going to have an overlap from the network your on remotely if you want to vpn into your network, etc. Which would be a problem. Such a large mask is normally used as a summary route or a firewall rule to include the whole chunk of rfc1918 space..
-
These are my rules.
I have blocked lan net to access to wan address, but it doesn't work and this rule is in the right place.
I use /16 because I have many subnet /24 there (as you see) and I use darkstat too and it doesn't work if I set /24 in lan interface (it doesn't monitor traffic from 192.168.X.0/24)
-
"I use /16 because I have many subnet /24 there (as you see"
Huh??? That makes ZERO sense.. So you mean your running multiple layer 3 networks over the same layer 2?? Yeah that is BORKED!!!
I have multiple networks as well, all in the 192.168 space.. They are on their own vlans, you do not run multiple layer 3 networks on the same layer 2.
So check your state table.. If there is a state then does not matter what your rules say. You would have to flush any existing state for block rules to work.
-
Huh??? That makes ZERO sense.. So you mean your running multiple layer 3 networks over the same layer 2?? Yeah that is BORKED!!!
Actually, no. it's long been possible to have an IPv4 alias address on a NIC. The alias would typically be on a different subnet. And with IPv6, it's expected to have more than one prefix available. For example, you could have both global unicast and unique local addresses on the same network, in addition to link local.
-
Block the access on the LAN rules, WAN rules do not apply on traffic that is either internal to the system or comes in from another interface.
-
"Actually, no. it's long been possible "
Possible - ok, yeah its been possible forever. Doesn't mean its not borked!!
Link local is not the same thing as running multiple ipv4 layer 3 networks on the same layer 2. link local is only layer 2 addresses, they do not route. Much like the ipv4 169.254.0.0/16 address space which is the ipv4 version. And no I would not use a local ipv6 network prefix (ULA) fc00::/7 if the device has a global ipv6 prefix. While yes devices can and will in many ipv6 setups use multiple IPv6 address, along with their link local address the non link local would all be in the same prefix.
So while sure you could put a ipv4 alias address on his pfsense for a different layer 3 address space.. This too would be a borked configuration. If you want to run multiple layer 3 networks then they should line up with your layer 2 network. So if you want to run 192.168.0/24 and 192.168.1.0/24 on the same physical interface then you should put them on different layer2 networks via vlans. If you put them all in the same layer 2 you have no security between them since they are all on the same wire.. So while you could put rules in place on pfsense that says 192.168.0.100/24 can not talk to 192.168.1.100/24 and normally route the traffic, etc. In reality those boxes are on the same wire and 0.100 can talk to 1.100 without going through your firewall rules. Not only would that be an issue, you also run into the possibility of asymmetrical communication. Since they are in reality on the same broadcast domain all the broadcast traffic, arps, multicast will be seen by all devices on that wire..
If he want so to have all his devices on the same layer 2 that is fine.. If he wants to use /16 because he wants them all on the same layer 2 that is fine. But thinking he any sort of isolation between his networks is not correct. And if he wants all his devices on same layer 2 then the layer 3 he is running on that layer 2 should all use the same mask ie /16, not /24 on what he is calling subnets which is not correct. If he wants them all on the same layer 2 then I would use the appropriate mask to reflect the number of devices he will have on that network.. /16 would be 65k devices - I find it highly unlikely he has that many, nor would be be a good idea to put that many ideas on the same broadcast domain.. Use a more realistic mask, /23 maybe a /22.. /21 but now your broadcast domain is getting quite large and could have issues with broadcasts.
Just because its "possible" to do something doesn't make it correct or best practice..
-
link local is only layer 2 addresses
While it may not route, link local is definitely layer 3. It's still IP. Also, the reason for unique local addresses is you may have devices that you want to access, but they don't have access to the Internet. You could do the same on IPv4 with global unique addresses and RFC1918 addresses on the same interfaces. IPv6 supports multiple scopes, with the intention they will be used as appropriate.
-
You know what I meant.. Is not a routable address. Its ONLY viable on the same layer 2 network.. ;) But you are correct it is a layer 3 address… hehehe
"You could do the same on IPv4 with global unique addresses and RFC1918 addresses on the same interfaces. "
Sure you could do that.. But again your taking about the same layer 2 without any desire to isolate... That is NOT what the OP is talking about.. He doesn't want network A talking to network B!! Which means they need to be on different layer 2.. Or they can talk to each other no matter what you do at the firewall since they are on the same wire no matter what layer 3 IP address you give them..
If I was going to put non rfc1918 address on an interface - it would be completely BORKED to put a rfc1918 address on to be honest without isolation.. So while you might do that as a vlan on the interface. Why would you multihome a device and put rfc1918 on same layer 2 network as public IPv4?? What purpose does it serve to do such a thing?? Give a viable example were that would make sense to do please.. Other than a complete hack because you don't have a way to isolate at layer 2 and some odd reason you need to have multiple IPs on this box/device.. Ie it would be BORKED...
-
Dear boys,
thanks for your replies, but my problem is another one:
I haven't problem with subnet /16 or /24.. it was a try just for experiment, because darkstat doesn't work if I do /24. But this is a thing that doesn't care about my problem.
My problem is that clients on lan net (/24 or /16 is the same) can reach wan address though there is a block rule in rule lan section. I have investigated about that and I figured out that squid transparent proxy causes this issue, infact if I disable squid service the block rule is applied and clients don't reach wan address anymore.
So now, how can I fix this? I have found a solution by adding wan address in blacklist destination domains in squid's ACLs settings and it works! But I don't like very much, so I have inserted wan address in "Bypass Proxy for These Destination IPs" in squid settings and it seems work fine.
If you have others suggestions how to improve it, my ears are listening.Thank you all.
-
If your using a proxy, which you did not mention in your OP. Then yeah you would need to make sure the proxy can not go where you don't want the "proxy" to go.. So you have found the 2 solutions either tell the proxy not to go there, or setup the proxy not to proxy connections to that IP and then your firewall rules would allow or block the client.
As to darkstat not working.. Darkstat works just fine on multiple vlans, you just have to tell it.. No it would work correctly if your running multiple layer 3 networks on the same layer 2.. Set up your network correctly and your darkstat will work just fine..
-
I didn't think it was a proxy problem, for this reasons I didn't mention it.
About darkstat, I will setup vlans and try to get it working. -
So here for example just installed it and set it up for my different networks.. See its showing the multiple networks… I only left it running for a couple of minutes, so its only seeing 2 of networks... But you get the idea know I hope.
All of my 7 different local network segments are on different 192.168.x/24's..
-
Yes yes, I understand that you say. I know that with vlans is better for security and isolation, but as I said before.. it was only for experiment to get darkstat working, only for this purpose. Didn't know that darkstat works also with vlans, so now I will experiment it with vlans and I hope i get working like your setup! :)
Thanks for support