Cant connect to DMZ network from LAN
-
I have a public segment from my provider 1.1.1.16/28. I set up that segment on my DMZ 1.1.1.30/28. This interface does not have a GW assigned to it. My LAN is 192.168.1.0/24. I have a server connected to 1.1.1.17/28 and it is able to connect to the internet via .16 as it GW and external users are able to ping it and ssh into it. From my LAN I am not able to ping it or anything. My laptop only has 1 interface and when I do a trace route to 1.1.1.17, it attempts to go out to my providers default GW instead of routing it to the DMZ interface. Also when I do a ping on the pfsense from the LAN to the DMZ it appears to work, but not from any other computer on my LAN. Furthermore I am not seeing any block attempts on the firewall rules. I know that at one point this was working, but not sure what happened. I have made numerous changes to this firewall and not sure if I broke it, or an upgrade or something else.
Any suggestions? -
@mrjoli021
Provide a network map, please, to clarify how your networks are connected. -
Hello,
I have a /30 from my provider. On the firewall I have three interfaces an LAN, WAN, and DMZ. The DMZ. Right now I have a server physically connected to the DMZ. That server is accessible via the internet, but not accessible from any users in my LAN. This server is excluded from the NAT table so it's public IP is exposed and the users are using the /30 for NAT. The switch is an L2 Switch which does not Routing. Users are able to browse the internet without any issues.
-
@mrjoli021 said in Cant connect to DMZ network from LAN:
This server is excluded from the NAT table so it's public IP is exposed
How is this done exactly? Above you wrote the server has a public IP. Is this correct?
So if you do not NAT you might route the traffic from WAN to the server, right?And you try to access the server from LAN by its IP or by its public FQDN?
-
The provider is giving me a /30 2.2.2.0 .1 is on the provider side and .2 is on the WAN interface. The 1.1.1.16/28 is a public range provided to me from the provider. .30 is on the DMZ interface. The server has a .17 assigned to it. This is the only IP on this server and when it routes out to the internet this is the IP it is reachable by, also this is the outbound IP as well. This is done by creating an outbound NAT On the LAN side 192.168.1.0/24 is the LAN network and .1 is on the LAN interface. From a device connected on the LAN, lets say 192.168.1.100. This device is attempting to access 1.1.1.17. It does not work. What am I missing?
-
@mrjoli021
The gateway is the firewall on all involved devices and all network masks are set correctly? So the laptop has set 192.168.1.1 as gateway and the server 1.1.1.30.
Then it should work in fact presumably a firewall rule allow the access.You wrote, the packets try go out to to WAN instead of passing to the server. Did you check this out by packet capture?
-
That is why I am trying to get help. I have tried the obvious and your right is should work, but for some reason it is not. When I do a trace route from the laptop it attempts to go out through .2 of the WAN interface out to the internet. Also I have checked the firewall rules and nothing comes up on the rules. Finally I did a tcpdump on the server and nothing is showing up from the laptop.
-
@mrjoli021 said in Cant connect to DMZ network from LAN:
When I do a trace route from the laptop it attempts to go out through .2 of the WAN interface out to the internet
Use Diagnostic > Packet Capture on pfSense to investigate this in details, while initiating an access to the server from LAN. Take a capture on all interfaces, best simultaneously to check out where the packets are moving to.
The only reason I can think off for packets are directed out to the default gateway is that the servers IP lies outside the DMZ subnet (wrong mask).
-
Thanks. That was it. All this time troubleshooting and it was something really simple. Somehow I guess I ended up switching the mask to a /24, not sure why but that is what it was set to. Once I changed it to a /28 everything is now working. I should have picked that up from the beginning. Thanks again.
-
@mrjoli021
So really not clear, why the access worked from the WAN side though. But something to keep in mind.