Pfsense won't route tcp 135 out of LAN, and no logging
-
So i we found this out when changing to Pfsense in our data center.
We have a setup like this:
Windows Terminal server on one side, and the domain controller on the other side.
The terminal server needs to communicate with the domain controller for basic function.Everything worked fine, before we change to pfsense.
Pfsense somehow blocks port 135 tcp, from leaving the LAN.
But not all the time, it allow some through, and then blocks it, then after some time 30 seconds, its unblocked again. Then it blocks it again.How do i know it is pfsense? Because it worked before we installed our new netgate hardware.
And when we add static routes directly on our terminal server, and not in our pfsense router, it works just fine again. And the other way, from the DC to the TS there is no problem. There is only a problem when pfsense is a part of the route.How do i disable this? and where are options for this kind of behavior?
-
@professor Well, using pfSense for L2 routing to a Gateway on the same interface as the incoming traffic, still makes it apply its pf filter rules.
TCP 135 is normally for RPC - which means negotiating different dynamic ports to actually complete the exchange on. Depending on the negotiated direction and ports, that exchange may or may not be allowed by your filter rules on the LAN interface. Return traffic will by any means be returned directly to the client (pfSense not involved), so it will be considered asymmetric routing in any case by pfSense, and blocked.Its pretty bad network design to create your setup like that, but if your insist, you need to disable applying pf filter rules to L2 routing on the same Interface. This is done in the SYSTEM -> ADVANCED menu under advanced -> static route filtering
Love the no fuss of using the official appliances :-)
-
@professor said in Pfsense won't route tcp 135 out of LAN, and no logging:
worked fine, before we change to pfsense.
Pfsense somehow blocks port 135 tcp, from leaving the LAN.
But not all the time, it allow some through, and then blocks it, then after some time 30 seconds, its unblocked again. Then it blocks it again.
How do i know it is pfsense? Because it worked before we instaI take it this wasn't a 1 for 1 swap....
-
@keyser said in Pfsense won't route tcp 135 out of LAN, and no logging:
Its pretty bad network design
Concur.. That is going to be nothing but PITA..
The connection between your 2 different pfsense there should be via a transit network, so there is no asymmetric traffic..
-
@keyser Thank you.
This finally makes sense.
But if i wanted pfSense to apply firewall rules, i would place the gateway on an other interface. This is the way our other equipment (Unifi) works.Thank you again :)
-
-
@professor said in Pfsense won't route tcp 135 out of LAN, and no logging:
we don't want pfsense to interfere with the traffic, just route it.
Then do that - any any rule there you go..
-
No. That is exactly the problem. Without the option ticked to disable static route filtering. AND with a Any any rule, Pfsense lets some through, and then blocks it. Then some traffic can pass again, then it blocks it again. All without loggin anything in the firewall logs.
-
@professor said in Pfsense won't route tcp 135 out of LAN, and no logging:
No. That is exactly the problem. Without the option ticked to disable static route filtering. AND with a Any any rule, Pfsense lets some through, and then blocks it. Then some traffic can pass again, then it blocks it again. All without loggin anything in the firewall logs.
Yes, in your setup the return traffic never passes the pfSense, and is therefore returned assymetric. pfSense by default is fully statefull - even when routing traffic out the same interface as it came in.
In your case that means the client will get answers on the first request, but any subsequent packets in the same session will be blocked (because they are out of session from pfSenses point of view).The USG’s on the hand does not do Statefull filtering on “same interface routing”, so it will just route regardless of the traffic being assymetric.
You can have pfSense do the same by using the static filtering switch :-) -
You sure about that?
Without the option ticked to disable static route filtering. AND with a Any any rule, Pfsense lets some through, and then blocks it. But this is ONLY port 135 TCP.All other traffic works great. Everything. Both ways.
That is strange. -
@professor said in Pfsense won't route tcp 135 out of LAN, and no logging:
You sure about that?
Without the option ticked to disable static route filtering. AND with a Any any rule, Pfsense lets some through, and then blocks it. But this is ONLY port 135 TCP.All other traffic works great. Everything. Both ways.
That is strange.Up until now I thought I was…
The problem could relate to whether you get a ICMP redirect and your Client starts sending traffic directly to the other Gateway (skipping your pfSense). Depending on your rules, if initial traffic is allowed, an ICMP redirect could be issued to your Client and session traffic is sent directly to the other Gateway.
But using TCP135 the 135 port session is only used for negotiatiating another port and direction the session. This alternate traffic might not be passer by your rules, or if the direction is reversed, pfSense never sees the session establishment, and just Blocks the assymetric traffic (or No ICMP redirect is in place to skip pfsense)But I might be mistaken…
-
@professor your setup is a MESS.. Yeah your going to have problem with it, its a asymmetrical nightmare..
Fix it! Use a transit network - now you can just use pfsense as a router with a any any rule..
