A question about a (likely) routing problem
-
@stephenw10 said in A question about a (likely) routing problem:
hello @stephenw10 thank you for your reply.
Is that supposed to be a different host?
HOST A and HOST B are two different hosts.
HOST B has two IP addresses (192.168.120.10 and 172.16.3.10)thanks,
Mauro -
@mauro-tridici said in A question about a (likely) routing problem:
HOST B has two IP addresses (192.168.120.10 and 172.16.3.10)
Ah, that's the problem then. Host B can reply directly to Host A creating an asymmetric route.
Do you see blocked traffic in pfSense when it fails?
The time span implies something is probably sending an ICMP redirect that then expires.
Steve
-
@stephenw10 said in A question about a (likely) routing problem:
Ah, that's the problem then. Host B can reply directly to Host A creating an asymmetric route.
Ok, thank you. I'm trying to understand the "asymmetric routing" concept reading the link provided by SteveITS. I hope I can fix it in some way.
Do you see blocked traffic in pfSense when it fails?
No, it seems that there is no blocked traffic in pfsense firewall logs
The time span implies something is probably sending an ICMP redirect that then expires.
Steve -
Good morning @stephenw10 and @SteveITS
I read the official link content mentioned above and I applied suggested actions related to the manual fix section, but SSH still freezes after about 30 seconds.
Recap: I tried to start an SSH connection from host A (IP 192.168.120.111) to host B (IP 172.16.3.10). Since host B has also the additional IP 192.168.120.10, SSH connection freezes due to the asymmetric route.
This is what I have done.
Let's say that:OPT1 is the pfsense interface related to 192.168.120.0/24 network;
OPT2 is the pfsense interface related to 172.16.0.0/20 network;on interface OPT2, I added the following rule:
from OPT2 net to 192.168.120.111 allow any, TCP flags - Any flags, State type SloppyIn floating rules, I added the following rule:
from OPT2 net to 192.168.120.111 allow any, TCP flags - Any flags, State type SloppyUnfortunately, SSH connection is still freeezing.
Could you please help me to understand where is my fault?Thank you,
Mauro -
@mauro-tridici If they're both on the same two networks the reply traffic isn't going to go through pfSense. Host B knows it can reply directly.
Any reason you can't just SSH to 192.168.120.10?
-
Yes, you really need to be removing the asymmetry rather than trying to force pfSense to pass it.
The fact you're not seeing blocked traffic in pfSense means it may not be getting blocked there. It could be one of the hosts blocking the traffic from outside it's subnet.
-
@steveits thank you for you reply.
I can just SSH to 192.168.120.10 directly, you are right.
Anyway, I'm trying to understand if there is a way to fix this behaviour or, at least, I would like to understand how I should "react" when this scenario occurs.Most of the currently running hosts have two IP addresses, one for management purposes and the other one for data traffic.
Should I simply connect from (to) IP on the same network leaving the asymmetric routing problem still there?
Sorry for this stupid question, but I would like to understand if fix is really needed in any case.
-
@stephenw10 thank you Steve.
As you know, I'm a newbie and I'm still studying.
This is a stupid question, but I need to do it to.In order to remove the asymmetric, I simply need to connect to IP addresses belonging to the same network? Or I should remove one IP address from the host B?
Most of the currently running hosts have two IP addresses, one for management purposes and the other one for data traffic.
Can I ignore the asymmetric routing problem (because it occurs only in a particular case)?
Thank you,
Mauro -
Multihomed hosts are usually a bad idea because of exactly this sort of problem. You should only use them if there's really no other option IMO.
-
@mauro-tridici The path ends up being like this:
packet goes out from 192.168.120.111 to 192.168.120.1
192.168.120.1 sends the packet to 172.16.3.10
The PC at 172.16.3.10 doesn't need to use a gateway, it knows how to talk to 192.168.120.111, because it's on that network, so sends a response out from 192.168.120.10 to 192.168.120.111
192.168.120.111 is not listening for a reply from 192.168.120.10 so ignores it
