Pfsense source based routing seems broken
-
source based routing seems to work but don't perfectly
sometimes, I see that a pc (ip: 192.168.0.88) go through pppoe0 instead of pppoe1I have set a rule for source based routing, for which this pc must go through pppoe1
It seems when the destination ip has been reached by other machine through pppo0, it use the same pppoe0 also for 192.168.0.88
-
you mean policy based routing? Via rule that forces traffic out a gateway..
Could you please post your rules that are doing the routing. Are you using any sort of load balance or failover between the 2 gateways?
-
you mean policy based routing? Via rule that forces traffic out a gateway..
yes
Are you using any sort of load balance or failover between the 2 gateways?
No, nothing of that
I have three separate pppoe connections -
Yes simple screen shot.
Also keep in mind that rules can be set to be skipped if a gateway is down.. So depending on how you have your rules set if a gateway is down then traffic could go out a different gateway even if not using failover gateway groups, etc.
-
screenshots:
https://s1.postimg.org/430m48z667/image.png
https://s1.postimg.org/4vdhlzhhmn/image.png
https://s1.postimg.org/5yd6wvbthp/image.png
https://s1.postimg.org/4kqnsu2owt/image.png -
adding them to the thread is much easier!
So do you have pfsense set to skip rules if gateway down.. Can see that your gateways have different uptime.
Plus your policy routes are set for TCP only so yeah that would fall through and other protocols would go out your default gateway.
BTW what is the mask you have sources in 0.88 and 2.88? And if the connections were IPv6 they would just go out your normal gateway.. So what exactly are you seeing not go out your policy rule?
-
Much easier for those from whom you are asking for help, anyway.
-
mask is 255.255.0.0 for all ip in the network, ipv4 only
So what exactly are you seeing not go out your policy rule?
from ip 192.168.2.88
If I check my ip with
lynx –dump http://tttxmh.altervista.org/myip.php
I get the ip of 79.33.xxxxxx instead of 79.62.xxxxxxxx -
I think you miss the point….
 -
Ok - I have to ask why? Since its one of my pet peeves, a /16 makes no sense on network. It makes sense as /cidr in some firewall rule or summary route.. On a network wow.. You have some 65k nodes? ;)
But back to the topic at hand.. Your 2 policy route rule has not seen any hits at all. And again its only tcp.. So no it would not route traffic say udp or icmp out that gateway.. So what traffic are you seeing that is not going out your gateway?
"from ip 192.168.2.88"
From your rules listing there are no hits on that rule.. So is it using some other gateway?
Did you clear states after creating that rule.. That could also cause your problem.. If you client went there before you put in the rule, then there could be a state already, etc.
-
Ok - I have to ask why? Since its one of my pet peeves, a /16 makes no sense on network. It makes sense as /cidr in some firewall rule or summary route.. On a network wow.. You have some 65k nodes? ;)
no, but there are a lot of fixed ip in different places like 192.168.0.* 192.168.2.* 192.168.29.* 192.168.17.* 192.168.195.* etc so a with a /16 it's easier to communicate in lan
I should change a lot of Ip, and it's a lot of work with printer etc -
So just plain bad management ;) And then laziness vs fixing ;)
-
So just plain bad management ;) And then laziness vs fixing ;)
In these days I'm trying to change machines IP to 192.168.2.0/24 and use pfsense as dhcp server but it's difficult, for example I don't understand how to give to a particular MAC-address gateway:nothing and dns:nothing instead of gateways and dns passed to all other machines
-
In your reservation just hand out loopback to that client 127.0.0.1 if you don't want it to have a gateway or dns that works.
But if you don't want it the client to get out or use dns on pfsense. You could also just firewall it.
-
In your reservation just hand out loopback to that client 127.0.0.1 if you don't want it to have a gateway or dns that works.
yes, but it's strange…
why to use this workaround?? wouldn't it be easier to give nothing as gateway and nothing as dns?
where's the problem? with dhcpd or with pfsense? -
A DHCP static mapping should probably accept none like the main configuration does.
-
no, it doesn't work with none:
it says:The following input errors were detected:
A valid IPv4 address must be specified for the gateway.I need to provide only ip address and netmask nothing else
-
dhcpd can be set to not hand that out.. So prob just something in the validation script not allowing for the none entry.. Could put in a feature request for sure on that.
Simple work around though is just loopback.
But to be honest this is got to be a rare sort of use case..
-
Right. I was saying it should accept none there, at least if it is possible to do an override like that in ISC dhcpd.
That would be a feature request.
Yeah, a static config of that single host seems like a workaround in your case.
