[SOLVED]Webserver not working with a /16 LAN
-
Hi, I've been configuring a few pfsense machines without problems, but today I found a weird one.
Until now I always had a /24 network as LAN and everything worked perfectly. But today I had to setup a 192.168.1.1/16 LAN interface and started having some problems.
When a client computer with an ip of "192.168.2.50" tried to connect to a web server at 192.168.1.3 the default deny rule ipv4 blocks the traffic and the client can't load the page. (The log at the firewall shows the webserver as source of the blocked connection from 192.168.1.3:443 to 192.168.2.50:56768 (keeps randomizing that port))
But when a client with an ip of "192.168.1.235" attempts to connect, it works instantly and perfectly.So...what is going on here? It seems the firewall is blocking traffic from 192.168.1.0 hosts to 192.168.2.0 by a default deny rule...but only when it's the 443 port...as for example ping between hosts works fine...tried adding a LAN rule allowing all traffic between 192.168.2.0/24 and 192.168.1.0/24 but still gets blocked... (Also the default LAN rule of allowing all traffic should include that range as LAN interface is configured as 192.168.1.1/16)
I've been smashing my head for hours and can't find a solution, I'm new to all this so I wouldn't be surprised if it's some stupid issue with an easy fix.
Well, I hope someone can help me with this, thanks in advance.
-
Check the subnet masks.
It's not a pfSense issue as both devices are on the same subnet.
-
You mean the client and webserver subnet masks?
I'm sure the client has 255.255.0.0 but didn't check the webserver config.Anyway, it worked perefectly until I configured the pfsense machine...actually if I turn off the pfsense machine it starts working again.
-
Both.
If they are on the same network packets wouldn't even hit the router.
-
Ok, I'm gonna check the webserver config and let you know. But probably I won't be able to test it until monday as the office where is configured closed already.
Thanks. -
@Agustinp said in Webserver not working with a /16 LAN:
When a client computer with an ip of "192.168.2.50" tried to connect to a web server at 192.168.1.3 the default deny rule ipv4 blocks the traffic and the client can't load the page. (The log at the firewall shows the webserver as source of the blocked connection from 192.168.1.3:443 to 192.168.2.50:56768 (keeps randomizing that port))
But when a client with an ip of "192.168.1.235" attempts to connect, it works instantly and perfectly.That screems subnet mask. If a Client of ...1.x can work with the server being .1.3 -> they are both in the same /24. If your client is .2.50 and doesn't - I'd bet the server is configured with .1.3/24. Because of this, the server sends all requests to .2.50 to its default gw -> the pfsense - that would block the traffic because it is out of state (not syn but syn ack). So as others already told: it's no pfsense problem but ill configured host/client configs :) If those would be right, the traffic would never even hit pfSense as all IPs you mentioned are in the same /16 subnet and thus would never send traffic to their default GW as they can communicate locally.
-
Thank you for the explanation, I'll check that first thing in the morning on monday.
-
Also: it's generally not a good idea to put 65000 hosts in the same broadcast domain
-
For curiosity sake - why would you be setting a /16 on anything? Other than a summary route, or a firewall rule such mask makes little sense of any sense to use..
Lets hope you don't have any sort of vpn clients are you going to have issues with anyone using anything in the 192.168 space..
If you have need for more than /24 space - ok /23 say even a /22.. Or just segment and route between your local networks.. Using such large network makes really no sense at all.
The reason you can have problems with mismatched masks is 1 of the devices will think oh that network is local, will send to the client directly is on my local network.. The other device will say oh I need to talk to 192.168.X but thats not on my 192.168.Y network - need to send that traffic to my gateway.. which is going to asymmetrical..
Use a mask that is appropriate for the number of devices on your network. Which never going to be 65k ;)
-
@johnpoz said in Webserver not working with a /16 LAN:
For curiosity sake - why would you be setting a /16 on anything? Other than a summary route, or a firewall rule such mask makes little sense of any sense to use..
Lets hope you don't have any sort of vpn clients are you going to have issues with anyone using anything in the 192.168 space..
If you have need for more than /24 space - ok /23 say even a /22.. Or just segment and route between your local networks.. Using such large network makes really no sense at all.
The reason you can have problems with mismatched masks is 1 of the devices will think oh that network is local, will send to the client directly is on my local network.. The other device will say oh I need to talk to 192.168.X but thats not on my 192.168.Y network - need to send that traffic to my gateway.. which is going to asymmetrical..
Use a mask that is appropriate for the number of devices on your network. Which never going to be 65k ;)
Yeah I know, /16 is a bit too much, it's a facility with a lot of users but still I think a /22 was enough.
I guess I'll suggest to reconfigure that in a near future. -
@Agustinp said in Webserver not working with a /16 LAN:
Yeah I know, /16 is a bit too much, it's a facility with a lot of users but still I think a /22 was enough.
Even though, why not simply using VLANs and separate users/clients in that process? VLAN segmentation based on user groups or the like are recommedable from a security viewpoint anyway. Packing servers/service hosts into a server VLAN and using a few client VLANs and limit their access accordingly and get a nice security benefit out of it in addition to doing clean routing and not (ab)using a /16 subnet for ~500-600 clients :)
-
Hi guys, confirmed, the webserver had the default /24 subnetmask, changed it and everything works now.
Thank you for everything :)
