On Wed, Nov 23, 2011 at 5:18 PM, Ron Lemon <[email protected]> wrote:
>
> Good Afternoon,
>
>
>
> I have an odd problem that I am hoping someone might be able to assist me 
> with.  I have a pfSense 2 box with 2 NICs in it.  WAN and LAN.  The LAN has 3 
> subnets on it 10.0.0.0/24, 10.0.1.0/24 and 10.0.4.0/24.
>
>
>
> 1.       If I sit in 10.0.1.0 I can connect to an RDC server in the same 
> subnet with no problems.
>
>
>
> 2.       If I sit in 10.0.0.0 and try to connect to the same server as the 
> previous test my RDC connection drops and reconnects maybe once every minute 
> or two.
>
>
>
> 3.       If I sit in 10.0.0.0 and try to connect to and RDC server in 
> 10.0.4.0 it is rock solid.
>
>
>
> 4.       If I connect to the same 10.0.1.0 server as in 1 and 2 above from 
> outside the building and come in through the WAN it is rock solid.
>
>
>
> So it does not appear to be the server, it does not appear to be the switches 
> in the building, it doesn’t look like the FW as other paths on the same 
> interfaces work no problem.  I am stumped.
>

Guessing that one of the affected hosts is dual homed, so the firewall
only sees one direction of the traffic, and hence will eventually drop
the TCP connection as it starts looking like spoofed traffic. Can't
statefully filter with any firewall if it doesn't see both directions.
That or the other alternative is there is another router in the mix
somewhere that's routing the opposite direction traffic. There is a
work around to not keep state on traffic in those scenarios for the
most common case, where there is a static route involved, but that
wouldn't be applicable here. That's an ugly network in general with 3
subnets on the same broadcast domain, splitting that up properly into
VLANs or similar and hence fixing all the weird routing possibilities
you have in that scenario is the best option, and really the only
option if you need to filter between the subnets. Adding sloppy state
firewall rules for traffic passing between the internal subnets should
work around it too.
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list

Reply via email to