Firewall won't allow traffic to a single address on another subnet
-
I've been battling this for days now; in testing I changed pfSense as the gateway for each of the subnet involved putting a routing switch in its place, this allowed for the traffic to reach both way but I can't NAT to force traffic to the reverse proxy.
To connect to the host affected without opening a remote console or access to the same network, I can piggyback-SSH on other hosts that have an address on the same subnet (regardless if they're multihomed or only in that subnet) and then from those I can SSH to the blocked host. One of these hosts with L2 access is obviously the firewall itself, which was unable to ping the host--so, either the host is blocking access from the gateway or the firewall is blocking outbound traffic towards the host. Traffic coming through the gateway from another subnet would have as source the other subnet, right? NAT was going to be used but at that point it was still only routed traffic. Then it's the firewall that somehow has outbound traffic blocked.
The first rule I have on every interface is to allow all ICMP traffic, that leaves outbound blocks which require floating rules but none of my floating rules match.
I tested further by adding a new address to the blocked host and it was again pingable from everywhere on this temporary new address.
With confirmation that it is only a single address and none of my rules standing out I started reviewing the aliases but everything is OK.
BTW, like I said, I've been on this for days, on which I switched firewalls then reinstalled pfSense, selectively restored a backup which had been working fine but after trying to add the NAT rules I need (which are rules I have tested before) it broke and won't recover after undoing things.
I checked routing tables too and double check there is no NAT anywhere. The firewalll is not running things that could mess up routing tables until a restart is needed, e.g; OpenVPN.
Any ideas why the traffic is blocked?
-
@skilledinept said in Firewall won't allow traffic to a single address on another subnet:
host affected
Since you allow all rfc1918 between Z0009 - Z0011 interfaces, it looks like route issue on you host. Try to compare the "traceroute" from both sides to see if it resolve as should.
-
@mytsuu I deployed another server (with a new IP address) and all was normal again.
I redeployed pfSense without restoring anything from backup except for the aliases. It all seemed to be well again.
Two days ago a computer randomly lost Internet access after a restart, this is a Windows machine tightly overseen via Active Directory. It also was having issues reaching some, not all, hosts in other subnets. Basically same old, same old.
I didn't take any chances and wiped it clean to rule out GPO misconfigurations – rejoining the domain puts everything back automatically.
With the new ruleset, all logged, it's much easier to spot things, there were no misplaced or missing rules. All traffic pftop is able to see is to multicast addresses and some payload delivery to/from a couple of C&C servers:
In the firewall logs I think I saw traffic for the host in the wrong interface, but I didn't catch the direction, it may have been some response..or dyslexia (addresses are too similar). Regardless, I assumed what I think would be to the worst possible scenario, a bad NIC; retested and found out that if I change the IP address of the host for a manually assigned one, same subnet/logical and same physical path to the network, connectivity is restored fully. Traffic is seen again, it all works.
What if it is a DHCP misconfig?
(I'm realizing this just now, as I'm typing. BTW.)
It makes no sense because nothing has been changed recently. On the other hand, my DHCP server is Windows Server, designed to *u** itself up and **c* the user too in the process—makes perfect sense. Like all Windows Server hosts it's not allowed online but Windows gained the ability of ***k itself up long before Windows Update gave it a f*** up schedule. It's Microsoft's way of helping us get a high ROI on IT admin positions. :) Bless you Microsoft.
I'm not using the classless routes DHCP option, 123 I think, not that it matters to Windows. I reassigned the reservation and so far so "good". The same address I had assign manually to the host, that was working fine, now obtained via DHCP isn't working anymore. If this theory is correct it would explain perfectly the other issue weeks before since things worked one-way only between a clients' subnet and a servers' subnet; hosts in server/container subnets have statically assigned networking. There's DHCP but it's more like a failsafe/supplemental thing. Client-type hosts, though reservation-only, always use DHCP.
To be sure, I still need to wipe ARP caches along the path and get a packet capture but it's proving to be a nightmare to access file shares without Kerberos/DomainMembership in order to get a copy of Wireshark.
Routing tables were OK though... and seem OK in Windows too. If the lowest metric value of 25 is "OK" and it's over 255 for all routes except for the default gateway (25). Lots of questions. :/
At least now I feel a ease since it seems it's not a pfSense issue. :D There aren't many firewalls out there to turn to.
-
@mytsuu Almost forgot: thank you for answering. :)
The metric seems like a clue, AFAIK it should only go as high as 255, hex FF. Makes sense. It's an (basic) area I'm not that familiar with. The IPv6 metrics are nearing 4 digits, but if IPv4=8=255=FF, IPv6=8=FFFF=idon'tknowmath-65K-maybe makes sense, as much as that passing as a formula in my head.
