[pfSense] issue with routing between LAN subnets
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 List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] issue with routing between LAN subnets
2014-07-25 2:52 GMT+02:00 Erik Anderson erike...@gmail.com: 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 List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list Hi Erik, i would start with: Checking the FW-Logs in - System-Logs - there should be an entry then, which tells you also which rule blocks and what the incoming interface was. checking the interface configuation - Status Inferfaces in the WebUI checking the routing of the pfsense - netstat -nr - either at the console or at - Diagnostics - Command blah in the WebUI Cchecking the NAT-Setup of the PfSense if i remember correctly for checking the connectivity from the FW-Console, one has to pass the source-address and/or the interface to the ping command. this should bring you more insights and ideas on what is wrong. if i remember correctly, parts of the interface assignment got changed between 2.0.1 and 2.1 or so. but i can be mistaken with this. hth michael ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] issue with routing between LAN subnets
Thanks Michael - I actually got this sorted out, and replied to myself and the list with the resolution. Thanks! On Thu, Jul 24, 2014 at 8:26 PM, Michael Schuh michael.sc...@gmail.com wrote: 2014-07-25 2:52 GMT+02:00 Erik Anderson erike...@gmail.com: 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 List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list Hi Erik, i would start with: Checking the FW-Logs in - System-Logs - there should be an entry then, which tells you also which rule blocks and what the incoming interface was. checking the interface configuation - Status Inferfaces in the WebUI checking the routing of the pfsense - netstat -nr - either at the console or at - Diagnostics - Command blah in the WebUI Cchecking the NAT-Setup of the PfSense if i remember correctly for checking the connectivity from the FW-Console, one has to pass the source-address and/or the interface to the ping command. this should bring you more insights and ideas on what is wrong. if i remember correctly, parts of the interface assignment got changed between 2.0.1 and 2.1 or so. but i can be mistaken with this. hth michael ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
