Weird situation about accessing LAN to DMZ
-
Hi guys,
I have a weird situation here.
I cannot ping my DMZ servers from LAN. However if I login thru VPN I can ping them.
My LAN rules are set to any any currently for troubleshooting purpose but still I cannot reach them from my LAN.
My DMZ rules also allowed Lan to DMZ
Thanks
-
@vincentemmanuel said in Weird situation about accessing LAN to DMZ:
My DMZ rules also allowed Lan to DMZ
Your dmz rule would never come into play, traffic is evaluated as it enters an interface from the network its attached too. How would lan net ever be source of traffic into the dmz interface, from the dmz network?
You would need zero rules on the dmz interface for traffic from lan that is allowed to talk to dmz, because the state created when traffic from lan to dmz was allowed would allow the return traffic.
Common issues with talking to another vlan.
Device on the destination vlan firewall does not allow the traffic
Device on the destination vlan isn't using pfsense as its gateway
Device on the destination vlan mask is wrong, and thinks traffic from source vlan is on its own network and never sends answer back to pfsense.To prove it to yourself that pfsense is allowing the traffic and sending it on, sniff on the dmz interface for icmp traffic from your source IP, get a ping going - do you see pfsense sending on the traffic? Then your issue is with the device your trying to talk to on the dmz.
example, pinging 192.168.3.42 (device on my dmz, that I know will not answer).. from my 192.168.9.100 (lan device)
So clearly ping timesout, but as you can see from sniff on my dmz interface - pfsense sent on the traffic.
-
@vincentemmanuel Is the subnet mask correct on the DMZ host as @johnpoz mentioned.
If the LAN and the DMZ are consecutive networks and both /24 and you have a subnet mask of /23 on the host in the DMZ it wouldn't route traffic back via the gateway.
That might explain why the VPN works.
-
This post is deleted! -
That is that 172 box telling that 61, actually different IPs and that 134 that 22 is not available. Why do you have port 22 (ssh) forwarded to that 172 address?
Yeah your going to see lots of noise on the internet.. You shouldn't have ports open you don't want to have open.
The reason your seeing that in the sniff is you didn't filter for the source IP of your pings as I asked and just filtered on icmp most likely. But good thing really because now you know you have a lot of noise hitting that 172 box in your dmz on port 22.
actually quite a bit of it, that whole sniff your showing is only like 4 seconds.
edit: btw that 61 IP is from China, and that 134 is from Russia
-
Yup. Disable that port forward or restrict it to known source IPs only.
-
@johnpoz yeah that was a mistake as we just setup the rules last week, it's supposed to be allowed from lan side only.
However there's still something wrong with the pfsense routing as
- Lan cannot reach dmz in general except the firewall itself
- Vpn can reach dmz so it's not the device blocking it.
Sniff on lan proofs that pfsense did deliver the icmp to dmz but it kinda lost somewhere between pfsense and dmz
-
@vincentemmanuel said in Weird situation about accessing LAN to DMZ:
lost somewhere between pfsense and dmz
you sure you don't have the mask wrong on the dmz device.. If the mask is wrong and it thinks the lan IP is on its own network then no it wouldn't work, but if the vpn IP is different then that would work.
-
@johnpoz yes, the mask is not wrong. Can we add a custom route to force this?
-
@vincentemmanuel
My suggestion is to solve the root cause , not work around it.Since LAN and DMZ both are "Connected interfaces" , there should be no need for an additional route. Which btw. would have a lower routing priority than a Connected Interface.
If by any chance an added route would somehow solve the issue, it would clearly indicate a configuration error in the setup.
/Bingo
-
@bingo600 Yes. I wanted to solve this root cause but I have run out of options because like you say they are connected interfaces and if LAN is already set to any any rules, there is no reason why it cannot access the DMZ servers.
I have 2 WAN gateways, but that should be something out of this context.
Any other suggestions are welcome.
-
You should upload a bit more info , like the interface settings , route table and arp table (after pinging default-gw , from both LAN & DMZ).
And elaborate if you have made other NAT/Portforward rules.
Output from an ipconfig & route from a DMZ n server wouldn't be bad too.
Edit: Your servers aren't multihomed , are they ? - Multi active NIC's ?
/Bingo
-
@vincentemmanuel not sure how you think its a routing issue?
You stated you see pfsense sending on the ping.. This isn't a pfsense problem - this is problem with your device. If your saying the mask is correct, then the next logical thing is firewall.
So you see pfsense sending on the ping, but you get no response - how would putting some "route" on pfsense fix that?
@bingo600 brings up some good questions, are we missing a piece of the puzzle here? Like multihomed device in the dmz?
So why don't you again prove it to yourself and sniff on the device in the dmz your trying to ping.. Do you see it get the pings? If not then clearly they are being blocked/dropped somewhere between pfsense interface that you saw the pings leave via your sniff, and the device.
-
@vincentemmanuel said in Weird situation about accessing LAN to DMZ:
Sniff on lan proofs that pfsense did deliver the icmp to dmz but it kinda lost somewhere between pfsense and dmz
What about a pcap on DMZ? Does that show the ping leaving the DMZ interface toward the servers but no reply?
Do you see the servers ARPing for the LAN clients maybe?
What subnets are in use here exactly?
LAN is 192.168.9.0/24?
DMZ is 192.168.3.0/24?
What is the VPN subnet?You could workaround this with an outbound NAT rule on DMZ but you absolutely shouldn't have to do that.
Steve
-
@stephenw10 said in Weird situation about accessing LAN to DMZ:
What about a pcap on DMZ?
That is where I told him to sniff from the get go, that is where he took the sniff I would of thought, taking it on lan is sure a valid check that pfsense is even seeing the ask for ping to dmz device. But the whole point was to validate pfsense is sending on the traffic.
Sniff on lan proofs that pfsense did deliver the icmp to dmz
But I can see how this could be misleading... Where exactly was the sniff taken? But his lan rules show no policy routing so its not like pfsense sending it out some gateway if sees it on lan, unless there is a floating rule that either blocks it or policy routes the traffic.
-
Indeed, I'd be surprised if it wasn't leaving the DMZ. It's almost certainly an issue at the target server.
But it could be some NAT rule or IPSec perhaps. -
Thanks guys! Let me try my best to provide the details
LAN 10.65.1.0/24
DMZ 172.16.65.0/24
VPN 10.5.5.0/24I have an IOT network at 10.65.2.0/24
I have 5 servers in the DMZ with IP ending 11 20 25 30.
NAT 1:1
Not multihomed.Things I have done.
Turning off DNS resolver so that LAN access server via public IP (failed)
Capture Packet from LAN interface (ICMP sent successfully from pfsense)
Capture Packet from DMZ interface (No ICMP traffic from my LAN host)Yesterday I did a test, I swop LAN with IOT and now everything works.
I am not sure what is the root problem but I can conclude it is not the end devices and probably the "LAN" on pfsense has some special thing going on.
-
@vincentemmanuel do you have some rules you didn't show us on the lan? Above that any rule? Do you have rules in floating.
Like maybe block rfc or bogon ;) Have seen that countless times.. That is why it is always best to show full rule sets, not just some specific rule. From the posting you have on your lan above - that would allow all traffic and not send it out some gateway.
But for all we know you have block rfc or some other rule policy routing traffic? Also do you have any rules in floating tab?
-
@johnpoz Well I didnt show the entire LAN ruleset because during troubleshooting I moved the any any rules to the top so the rest didn't really matters since everything passed thru that.
As for the floating rules, here it is
-
@vincentemmanuel well floating wouldn't have any issues. What other rules did you have on lan that you moved. If you had created a state, that say for example sent it out a vpn interface or something, that could cause the issue.
Here is the thing, if your rules allowed access on lan, and you were not forcing it out a gateway, there would be nothing stopping the traffic from going out the interface the destination IP was meant for. Basic routing, pfsense has routes for all the networks its directly attached to.
The only other thing that would stop it from sending on the traffic would be if it didn't know the mac address of the IP your trying to send to. Since its directly attached to that network.
