Optional interfaces not working after 2.1 to 2.1.5 upgrade
-
I upgraded from 2.1 to 2.1.5 via the auto-updater last week. Since that time, I have been unable to ping either of my two DMZ interfaces from a host within those networks.
Here's what works and what does not work:
- DMZ hosts CAN ping another DMZ host.
- DMZ hosts CAN NOT ping pfSense interface.
- pfSense interface CAN ping DMZ hosts.
- Strangely, traffic is still being passed from the WAN to DMZ, and it follows the rules and NATing that is in place.
What I've tried:
- Disabling/Re-enabling the optional interfaces.
- Rebooting the firewall.
- Rebooting my smart switches just in case.
I'm kind of at a loss with this one. I thought it might be the switches, but I can ping everything in each subnet EXCEPT the pfSense interface, and the pfSense interface can ping all of them. The only other change that occurred was the addition of the Squid, LightSquid, and SquidGuard packages linked to the LAN after the upgrade. I'm unsure if this was an issue prior to the package. However, I have unchecked the "Allow users on interface" and "Transparent proxy" options and saved, and there was no change.
Any ideas?
-
Rule(s) on the DMZ specify a gateway? Guessing so, in that case your config wasn't correct to begin with, but the auto-added policy route negation rules were overly-permissive in some cases. If that's the case, add a rule on the DMZ allowing traffic to that interface IP without specifying a gateway.
-
No, the rules don't specify a gateway (i.e. they use "*"). I added a rule in the DMZ to allow absolutely anything, and I'm still unable to ping the DMZ interface. I did realize that the LAN is able to ping the DMZ interface, though. Essentially, any hosts on the DMZ VLAN are able to ping each other, but not 172.32.0.1 (the DMZ interface).
Any LAN host can ping both the DMZ interface and DMZ hosts. DMZ hosts simply cannot ping anything but other hosts in the DMZ subnet. This includes the pfSense interface, and also any public IP address.
-
172.32.0.1 is not a private IP. Since you said you were NATing to these addresses I assumed they would be. Is that a typo?
When you try to ping the DMZ interface from a host what is the error given? Anything appear in the firewall logs?
Steve
-
Yes, sorry. That was a typo. 172.30.0.1.
The error on ping is simply "request timed out".
I can't believe I missed the log entry for this. It appears that the ping from 172.30.0.67 to 172.30.0.1 was being blocked by the "Block private networks" rule. Unchecking this allowed traffic, but just from 172.30.0.67(??). The other hosts still can't reach the interface. It's my understanding that this rule should have no effect on traffic within the same subnet, so I re-enabled and saved, and it continued working on 172.30.0.67.
I manually added a rule allowing any ICMP from the DMZ network (and I even tried using individual host IPs) to reach 172.30.0.1 on the DMZ interface, but this had no effect.
I've attached an image showing the rule that is blocking the ICMP traffic.
-
You need to have 'block private networks' unchecked. That is blocking the traffic. It should in fact be blocking everything from hosts on the dmz subnet. You are probably seeing existing firewall states that are confusing matters.
Uncheck block private networks and then clear the state table.Steve
-
Resetting the states seemed to clear up the interface pings. I'm not sure why I confused the checkbox so thoroughly even though I could have just looked at the LAN config. Would this mean that only the WAN should ever have this enabled, unless it's nested within a private subnet for the WAN?
Thanks for your help!
-
Yes since you shouldn't ever get traffic from private IPs on the WAN unless, as you say, it's behind some other NAT. Even then you can can leave it on and it won't block outgoing traffic, or replys to that traffic, only unsolicited traffic from the private subnet.
If you aren't using NAT and have a routed network with public IPs internally you might also use it there.Steve
