Static Route filtering
-
Hello,
Can someone please explain this behavior to me?:
LAN network: 10.66.0.1/24
Static route added to pfsense: 172.16.0.0/16 network, 10.66.0.10 gateway (on the LAN network, separate V/LAN that never hits pfsense)
When rule is added to LAN Interface Pass: IPv4*, Lan net, 172.16.0.0/16
Connections to that network are allowed but time out. I see entries in my firewall logs: @9(1000000103) block drop in log inet all label "Default deny rule IPv4"
I read some other posts on the topic and turning on Static Route Filtering seems to resolve it, but I'm curious why my existing rule isn't allowing the traffic through? I'm hesitant to use the static route filtering as I don't understand what the other effects could be of enabling this.
Thanks in advance.
Mike -
Because you are trying to route traffic into and back out the same interface with a direct path from 10.66.0.10 back to the source address on LAN, breaking firewall states.
It's an asymmetric mess.
Make ANOTHER interface, not LAN, that you use to talk ONLY to the router that is currently at 10.66.0.10 and route 172.26.0.0/16 there.
Everything will work fine and you won't be reliant on ip redirects, special rules, etc.
http://www.cymru.com/gillsr/documents/icmp-redirects-are-bad.pdf
-
Thanks Derelict for the response.
I'm not sure if this is what you were recommending, but this is what I did:
I added a new VLAN to my network that only the pfsense and router for the 172.26.0.0/16 router are on, I created this network under 10.66.4/24. I created a interface for this network. I changed the gateway address in pfsense to the new network address, which is 10.66.4.10. I left the static route and the firewall rule that says that the 172.16.0.0/16 network should be accessed using the gateway. My firewall rule does not specify the gateway, just that it should pass all traffic.
I still observe the same behavior. TCP:RA and TCP:PA are being blocked on the LAN interface.
Mike
-
You'll have to draw a diagram.
Are you just seeing the log entries or are connections breaking?
-
Here you go. I'm not great with these diagrams, hope this helps. The left is the "before" and the right is the "after" taking your advice and creating the transport VLAN network.
The connection drops after 20-30 seconds when I telnet to a device on the 172.16.0.0 unless the static route filter is enabled. I'm able to connect just fine, which made diagnosing this problem difficult.

 -
What are additional LAN devices on the SG300? Is that in layer 3 mode? Is there an SVI (layer3) address on LAN on the SG300?
Look at this diagram and read the descriptions carefully.
172.29.1.1/24 would be your 10.66.0.1/24 LAN.
-
Yes the SG300 is in L3 mode. The additional LAN devices are no different than any other LAN network device, just utilizing extra ports.
For context, the 172.16.0.0/16 network is a video distribution network. The static route is only to manage firmware and control activities.
In the left diagram, the SG300 has a LAN address, 10.66.0.10 which was the gateway for the 172.16.0.0/16 network. The static route was placed in pfsense and I noticed the problem. If I added the static route in any of the LAN devices locally, there would be no problem maintaining connections to the 172.16.0.0 network.
Does the way that pfsense handles static route firewall rules prevent me from this setup? Your diagram seems to suggest that a better form would be to connect the SG300 to pfsense directly and eliminate LAN devices from the SG300. I can do this, but I thought my topology would be supported as-is.
-
Your design is unsound. It has nothing to do with pfSense, but stateful firewalls in general.
Just trunk the LAN VLAN over to the SG300. Do not put an SVI (Layer 3) address on that VLAN on the SG300 and you should be able to use untagged ports on that VLAN over there just fine for LAN hosts. Their gateway will be pfSense. Traffic between LAN and the 172.16.0.0/16 will have to hairpin in and out of pfSense on two different VLANs but the routing will not be asymmetric. As long as you're not getting up into the 100s of megabits per sec sustained it should work fine.
The switch will need a route for the LAN subnet with a gateway of the transport interface (10.66.4.1). This is probably already covered by the switch's default route. Firewall rules there will have to pass traffic for 172.16.0.0/16. See the diagram up there ^.
Your diagram seems to suggest that a better form would be to connect the SG300 to pfsense directly and eliminate LAN devices from the SG300.
Don't confuse the logical nature of that diagram showing the routing with the physical connections. The transport VLAN tagged through the switch to the SG300 is another connected interface as far as pfSense is concerned. It doesn't know or care what physical path is taken to get to the other side, outside the physical interface on which to put the tagged traffic.
-
This has been stable for a few weeks now, so thank you for your help.
-
Thanks very much for letting us know. Glad it's sorted out.