OK, I got this resolved by adding an explicit firewall rule to the main-LAN interface allowing traffic from that subnet to the voice-LAN subnet.
Previously, I had an "allow anything to anywhere" rule that would have permitted this. This rule also had some policy routing applied to it, sending matching traffic out of a certain WAN gateway. It would seem as if this policy routing matching behavior changed somewhere between 2.0.1 and 2.1.4 such that if packets match, it will still apply the policy routing instructions even if they're both local subnets. This is why I was receiving ICMP replies from my WAN next-hop. -Erik On Thu, Jul 24, 2014 at 7:52 PM, Erik Anderson <[email protected]> wrote: > Hello - > > This evening I upgraded to 2.1.4 and have noticed an odd issue > communicating between two of my LAN subnets. > > For the purposes of this example, I have main-LAN (192.168.3.1/24) and > voice-LAN (192.168.5.1/24). > > I have firewall rules in place on the main-LAN interface to permit > traffic to the voice-LAN. > > When I ping from my workstation on the main-LAN to a server on the > voice-LAN, I get the following: > > https://gist.github.com/anderiv/60bac6fb637192eb8419 > > That ICMP reply is coming from the default gateway of our WAN > interface. It makes sense that comcast is blocking RFC1918 addresses, > but the question is: why is this traffic being routed out the WAN > instead of to the voice-LAN? > > Here's a packet capture, taken on the main-LAN interface: > > https://www.cloudshark.org/captures/215fcc948bb7 > > All of this worked perfectly in the previous version of pfsense we > were at (2.0.1). > > Any insights into what may be causing this? > > Thank you- > Erik _______________________________________________ List mailing list [email protected] https://lists.pfsense.org/mailman/listinfo/list
