How to avoid asymmetric routing between subnets / VLANS!?
-
Hello,
I know, not the first time asymmetric routing is an issue, but I think it is more that worth to dig into that issue again.
I have divided my network in a couple of using VLAN’s, where each VLAN has its own IP-range. Each VLAN is mapped on an pFsense interface.- In the WLAN-rule table is determined which internet incoming traffic is allowed;
- In the LANx-rule-tables is determined which LAN outgoing traffic is allowed is allowed. That traffic can be destinated to:
o The internet
o Another VLAN / Interface. - In the floating rules I defined a couple of traffic types which should never leave the network.
The problem described here is related to inter VLAN-traffic.
If (TCP) traffic is generated in LAN-A destinated to LAN-B, the traffic is not correctly passed due to asymmetric routing. The Firewall logging is indicating TCP:S.
At first that sounded very strange to me, up to the moment I did some traces (tracert). That showed me that the routing is as follows:- Traffic is floating towards the LAN-address / gateway first (lets say 192.168.1.1) then
- It is directly routed to the destination IP (lets say 192.168.2.x)
And as expected the route back behaves identical - Traffic is going to the gateway (192.168.2.1) and then
- Directly to the source (192.168.1.x)
And that is indeed asymmetric.
The route IMHO should be
- Traffic towards source gateway (192.168.1.1)
- ** Than towards destination gateway (192.168.2.1) **
- Than to the destination (192.168.2.x)
Big question is why does this happen!! So I did some checks:
- Could my network allow traffic directly bypassing the FW NO!
- Has the source computer any knowledge of the destination (I checked ARP) NO
- Is there anything strange in the pfSense ARP table NO
- Is there something strange in the pfSense route table ………. perhaps
There are routes towards 192.168.1.0/24 and 192.168.2.0/24 that would be correct as long as those routes are only and I mean only accessible via the corresponding interface gateway!
As final test I disabled the interface of the second lan (192.168.2.0/24) and did start tracer again.
- Traffic is routed towards the internet now, since the 192.168.2.0/24 range is not owned by the FW any longer. Where I blocked it with a floating rule. Since the route is now changed, it is even more likely that the firewall (pfSense package) caused the problem.
So IMHO it seems that the problem the firewall has (asymmetric routing), is caused by .... the firewall it self !!
. If so IMHO a serious issue!From the security point of view, I do not see an acceptable workaround!
I assume that this problem also occurs when using IPV6 (I did not test).Hope someone has the solution.
Sincerely,
Louis
-
I'm not completely certain if I understand you correctly, but it seems that you have some confusion about what is and isn't asymmetric routing.
In your scenario you have two subnets 192.168.1.0/24 and 192.168.2.0/24 on separate network interfaces (A and B respectively), with a single device acting as the gateway for both and and as a firewall/router between both segments, correct?
For the purposes of routing and firewalling, VLANs are really no different from physical interfaces, so that distinction can be ignored.
Let's shorten those networks to 1.x and 2.x to save some typing.
Let's assume a client 1.10 wants to communicate with 2.10 and sends a packet there. It first sends it to 1.1 because it is its default gateway.
When the packet arrives at 1.1, the router consults its route table to see where the packet needs to go and sees that it has a direct link with 2.10, so it simply outputs the packet on interface B.
Notably, it does not need to send the packet to 2.1 because it is 2.1. Sending a packet to itself would be completely pointless.
The packet goes 1.10 -> router @ interface A -> interface B -> 2.10
When 2.10 sends a return packet, it of course sends it to 2.1, which is the same router. That router then sends it out of interface A to its destinations
so the packet goes 2.10 -> router @ interface B -> interface A -> 1.10
Because the return traffic traverses the same devices and interfaces in reverse, the routing is not asymmetric.
Now, I'm not sure what the actual problem with your firewall ruleset is if it's not working the way you expect, but I think you can rule out asymmetric routing as a possible cause.
-
Yeah, I don't see asymmetry there.
@louis2 said in How to avoid asymmetric routing between subnets / VLANS!?:
The Firewall logging is indicating TCP:S
That means the traffic is not being passed on the interface you are seeing those logged on. Check your rule set. In asymmetric situations you might see blocks for other flags like TCP:SA, TCP:FA because the firewall is seeing traffic for part of the TCP connection and it hasn't seen the TCP:S[YN] first because the TCP traffic is going through different interfaces, aka asymmetrically.
-
@Chousuke. Thanks for the replay. I have been away for a couple of days, so thats why I did not react earlier.
@Chousuke said in How to avoid asymmetric routing between subnets / VLANS!?:
I'm not completely certain if I understand you correctly, but it seems that you have some confusion about what is and isn't asymmetric routing.
In your scenario you have two subnets 192.168.1.0/24 and 192.168.2.0/24 on separate network interfaces (A and B respectively), with a single device acting as the gateway for both and and as a firewall/router between both segments, correct?
More exact
On physical level I have three interfaces:- one for my management LAN and
- the other two combined as lag carrying a couple of VLAN’s each VLAN having its own address range
Each VLAN is represented as pfSense interface
or the purposes of routing and firewalling, VLANs are really no different from physical interfaces, so that distinction can be ignored.
I agree
Let's shorten those networks to 1.x and 2.x to save some typing.
Let's assume a client 1.10 wants to communicate with 2.10 and sends a packet there. It first sends it to 1.1 because it is its default gateway.Yep
When the packet arrives at 1.1, the router consults its route table to see where the packet needs to go and sees that it has a direct link with 2.10, so it simply outputs the packet on interface B.
Exactly this is what IMHO should not happen!!!
compare it with a street, where my neightbours now where I live, and what my computer is. That should not give the right to pass my front door !!Notably, it does not need to send the packet to 2.1 because it is 2.1. Sending a packet to itself would be completely pointless.
I do not agree for two reasons:
a) It is causing an asymetric route
b) entering my house (vlan) should go via the frontdoor (the vlan gateway), for security reasons. The vlan gateway should determine what/who is allowed to enter my house not the naber!The fact that both gateways are implemented on the same router does not change that! (IMHO)
The packet goes 1.10 -> router @ interface A -> interface B -> 2.10
When 2.10 sends a return packet, it of course sends it to 2.1, which is the same router. That router then sends it out of interface A to its destinations
so the packet goes 2.10 -> router @ interface B -> interface A -> 1.10
>> I am confused, because that is exactly as IMHO it should be !! (but what does not happen, it is skipping interface A)Because the return traffic traverses the same devices and interfaces in reverse, the routing is not asymmetric.
Now, I'm not sure what the actual problem with your firewall ruleset is if it's not working the way you expect, but I think you can rule out asymmetric routing as a possible cause. -
I'll remove some of the non-relevant parts here
When the packet arrives at 1.1, the router consults its route table to see where the packet needs to go and sees that it has a direct link with 2.10, so it simply outputs the packet on interface B.
Exactly this is what IMHO should not happen!!!
compare it with a street, where my neightbours now where I live, and what my computer is. That should not give the right to pass my front door !!What I was describing only applies to pure routing only. It's only concerned with getting a packet from point A to point B via whatever routes it has configured. A firewall is a separate logical function that can be applied on top of routing to filter traffic, but they can of course be performed by the same device.
Notably, it does not need to send the packet to 2.1 because it is 2.1. Sending a packet to itself would be completely pointless.
I do not agree for two reasons:
a) It is causing an asymetric route
b) entering my house (vlan) should go via the frontdoor (the vlan gateway), for security reasons. The vlan gateway should determine what/who is allowed to enter my house not the naber!The fact that both gateways are implemented on the same router does not change that! (IMHO)
Your analogy doesn't really work. Instead, think of a network of isolated villages connected by passageways through a central hub. In such a case, you can only go from village A to village B by passing through the central hub, and two passageways.
The villages are the networks (you can move freely within one) and can contain multiple houses (clients), the passageways are the interfaces on your router, and the hub is the router. If there's no security personnel at the hub, people can move freely between villages, but if you add a guard, you can perform security checks. Does that make sense?
There's really only one gateway. It simply has two different addresses on two different networks, and as such it can route traffic between those networks.
If you do not configure any firewall, the router will pass all traffic that it has routes for.
The packet goes 1.10 -> router @ interface A -> interface B -> 2.10
When 2.10 sends a return packet, it of course sends it to 2.1, which is the same router. That router then sends it out of interface A to its destinations
so the packet goes 2.10 -> router @ interface B -> interface A -> 1.10
>> I am confused, because that is exactly as IMHO it should be !! (but what does not happen, it is skipping interface A)You mean for the return traffic? It can't skip interface A on the return path, because that's its connection to the destination network. (the router will obviously have to emit the packet out of an interface to transmit it to its destination). It will however skip hopping through the gateway address of interface A, because it is already at the device where that address resides.
-
At first lets thanks you for the response.
Before giving a reaction on what is yes or no asymmetric routing, let me repeat here that I personally do not like the fact that the FW does not filter subnet incoming traffic based on the rule set related to the subnet its own interface.
Back to asymmetric routing.
As mentioned before and traceable via e.g. tracert, traffic starting at 1.10 => 1.1 (GW) => 2.10 not passing 2.1 (GW) and same behavior on the return path.
You explained that this is not considered to be symmetric since originating traffic and return traffic are both floating via the same interfaces.
So if that is true same interfaces is a requirement and same IP’s is not.
However sometimes I see “TCP:S” related to traffic which can not be asymmetric (if you consider same interfaces as symmetric). Strange ….Note that as far as I can see there not an alternative reason for “TCP:S” to show up as described in the next paragraph. Since it concerns local and allowed traffic ….
Let me mention here a few other reasons that “TCP:S” can show up:
- Traffic is initiated on a subnet but not passed due to GW-firewall rules. So there is an initial TCP message towards the GW but there will never be an answer. As example, a lot of programs (windows is an “excellent” example) are starting connections to their 'company' many times a day. Frequently I do not like that, especially in case of servers so I block it.
- The destination does not answer or is not answering in time. Can be for all kind of reasons.
Whatever, I think it is important that the FW documentation should be very clear and precise about what exactly is considered asymmetric and what not.
Louis
-
TCP:S is the initial connection. There can be no asymmetry there.
That is either passed or not on the interface upon which that connection is received.