Gateway monitoring ip set results in all traffic going to that ip from that gw
-
i have had this issue on 2.1.5 as well as 2.2 that suppose u r on a multiwan environment with each gateway having a monitoring ip set to check link for up or down, now suppose i have set one of the gateways as default and set to fail over to other when the default is down would mean that all traffic should go out of the default one only and when that fails then only go out of the secondary gateway but what happens is any traffic u send to the monitoring ip of the non default gateway results in it going out of the fail over wan and no the default wan.
GW1 - monitoring ip 8.8.8.8 - default
GW2 - monitoring ip 8.8.4.4 - switch to default only if gw1 downthe above is how it is, now 8.8.4.4 is used only for monitoring gw2 but suppose i do a tracert or ping, inspite of gw1 being default, traffic to that ip goes out of gw2 which is unintended so how to get over this situation?
-
The system puts a static route in the routing table for the monitor IP that goes to the specified gateway all the time.
I suppose you could put policy-routing rules on LAN for that IP and LAN clients that use it should be routed by the policy rules, and thus will fail-over. In fact, if you have general failover/load-balancing policy rules, then that monitor IP is likely to be included and will thus already failover/load-balance.
Or find a monitor IP that you do not want to use for any real user traffic. -
Not sure if the negate rules come into play here. I thought they only applied to locally connected subnets but maybe if a static route is on place. :-
Try disabling them in System: Advanced: Firewall and NAT:
If you're not aware of them, as I wasn't, then you need to explicitly allow all traffic if you have policy routing in place with them disabled.Steve
Edit: That's a 2.1.X location, not sure how that applies in 2.2.
-
Not sure if the negate rules come into play here. I thought they only applied to locally connected subnets but maybe if a static route is on place. :-
Try disabling them in System: Advanced: Firewall and NAT:
If you're not aware of them, as I wasn't, then you need to explicitly allow all traffic if you have policy routing in place with them disabled.Steve
Edit: That's a 2.1.X location, not sure how that applies in 2.2.
well, some portion of what u said went over my head, sorry, but wouldnt it be good if pfsense only automatically created a static route in the routing table only for icmp and for rest followed the normal rules in place as the gateway monitor only sends out a icmp so then why by default route everything to that ip through that gateway where this ip is set as monitoring ip
-
I guess because it was done in the routing table, where there is no concept of IP protocol/port per route. Routes are just a destination gateway to use for each IP address/subnet.
I haven't given it much thought - I guess it may be possible to put rule/s in pf to do the policy-routing just for ICMP that originates from the firewall itself and is going to each of those monitor IPs. That would leave the real users unaffected, as you suggest. -
Are you using those servers for DNS as well? Because that's a bit of a special case, you have to have DNS servers on each WAN.
Let me preface this with, in 2.1.X… I'm not sure how this may have changed in 2.2.
When you have a policy based firewall rule in place to direct traffic via a specific WAN there's a good chance that traffic will be caught by the rule that wasn't intended to be. For example traffic to another local LAN might be caught and directed via a WAN. That traffic will then fail because it's not accessible via the WAN. To prevent this pfSense puts in some firewall rules, that do not appear in the firewall rules table, to negate policy based routing for locally connected subnets. When this was first introduced, in 2.1?, it caught me out because I had rule-sets in place that relied on not being able to access local subnets when policy rules were in place. I have it disabled on my home box which means I need additional firewall rules in place to allow access to local subnets above any policy rules.
If you have a static route in place the negate rules may pick this up as a local network and bypass any policy routing. Just a guess though! ;)As far as I know it's not possible to do policy routing of traffic originating on the firewall. All traffic uses the default route. I guess a static route supersedes that.
Steve
-
I guess because it was done in the routing table, where there is no concept of IP protocol/port per route. Routes are just a destination gateway to use for each IP address/subnet.
I haven't given it much thought - I guess it may be possible to put rule/s in pf to do the policy-routing just for ICMP that originates from the firewall itself and is going to each of those monitor IPs. That would leave the real users unaffected, as you suggest.exactly, the icmp to those monitor ip go directly without going through the pf and also its not possible to know which client will be sending traffic to that ip so it would be good if pfsense could send that icmp for monitoring through the pf with auto created rules or something in the back end which can be overridden if necessary as i have a few boxes here which have more than 3 wan connections with the last one being a 3g connection and to get hold of so many different ips is a pain coz at times the ips go dead or they disable ping on them and i believe most might be using the google dns servers as monitoring ips as they r easy but just few days back one of those ips disabled ping or something went wrong so i had to change the ips for all the boxes under me and if by mistake i use the google dns and set it to the 3g connection as monitor, that causes the whole name resolution to crawl
-
on some boxes i use the google dns and also on some i use that as monitor ips, i have no other static routes and only one subnet on my lan, all these boxes r mainly used for internet access and/or load balance and failover