Default route not being set?
-
I've got a simple multi-WAN with two pptp links over a single subnet.
For some reason if one GATEWAY is the "default" if it's down the second gateway is not set as the default. This obviously causes routing issues, even for traffic from the router.
Is this a known issue?
-
That is expeted behaviour.
Please show your config because something might be wrong on you plolicy route.
-
Hi,
I also have that problem :-[
When the default gw is down I can't even access the webinterface remotely although I enabled that port on all wan interfaces.
Is there something needed to elect a new default gw when the first is down?
-
@ermal:
That is expeted behaviour.
Not sure I understand this? If there is no system default route set or switch on WAN change what happens to traffic originating from the router? Or from sources that don't use gateway groups?
Second thing I notice was I think a potential conflict between a GATEWAY firewall rule and traffic to vpns. I'll do a separate post on this.
@ermal:
Please show your config because something might be wrong on you plolicy route.
It's pretty basic. I also noted that the defaults latency limits (not sure exactly what they are) seemed to be too low, as I was getting high latency warnings. One of my dsl connections uses interleaving so it can sit around 40ms.
I'm using this now at home. I'll try some unplug connection tests later when it's less distributive.
Overall I like the direction it's going. Some of the network UI/logic is probably a bit rogue and not 100% intuitive. But it seems usable now.
<gateways><gateway_group><name>GATEWAY</name> WAN|1 WANORC|1 <trigger>down</trigger></gateway_group> <gateway_item><interface>wan</interface> <gateway>dynamic</gateway> <name>WAN</name> <weight>1</weight> <monitor>58.28.15.31</monitor> <latencylow>25</latencylow> <latencyhigh>250</latencyhigh> <losslow>1</losslow> <losshigh>4</losshigh></gateway_item> <gateway_item><interface>opt1</interface> <gateway>dynamic</gateway> <name>WANORC</name> <weight>1</weight> <monitor>60.234.8.201</monitor> <defaultgw><latencylow>25</latencylow> <latencyhigh>250</latencyhigh> <losslow>1</losslow> <losshigh>4</losshigh></defaultgw></gateway_item></gateways>
-
@mxx:
Hi,
I also have that problem :-[
When the default gw is down I can't even access the webinterface remotely although I enabled that port on all wan interfaces.
Is there something needed to elect a new default gw when the first is down?
[/quote]I did note that it seemed to take some time for a down interface to be detected. Not sure how to change the timeout.
-
@mxx:
Hi,
I also have that problem :-[
When the default gw is down I can't even access the webinterface remotely although I enabled that port on all wan interfaces.
Is there something needed to elect a new default gw when the first is down?
[/quote]I did note that it seemed to take some time for a down interface to be detected. Not sure how to change the timeout.
Something very strange I'd like to add is that when I mess around with the default gateway's Monitor IP, I get a timeout as soon as I click save. From that time on I can't access the webinterface remotely anymore.
I then have to login from the lan side, navigate to routes and hit apply. Then everything works again immediately from the remote side..Even more strange is that it's not even needed to change ANYTHING.. just open default gw's settings, click save.
As soon as I do that I can't access the firewall over any external ip/interface anymore.
After 5 minutes of waiting it didn't resolve..
had to access it via lan interface and hit apply..
-
@mxx:
Something very strange I'd like to add is that when I mess around with the default gateway's Monitor IP, I get a timeout as soon as I click save. From that time on I can't access the webinterface remotely anymore.
I then have to login from the lan side, navigate to routes and hit apply. Then everything works again immediately from the remote side..Even more strange is that it's not even needed to change ANYTHING.. just open default gw's settings, click save.
As soon as I do that I can't access the firewall over any external ip/interface anymore.
After 5 minutes of waiting it didn't resolve..
had to access it via lan interface and hit apply..Can you check the route table when you do this before and after. See if the system "default" disappears.
-
yes it does disappear
-
@mxx:
yes it does disappear
This is why you obviously can not access the system remotely.
I think some work needs to be done on the logic concerning the "system" route table and "policy" route tables. Losing the system default route table does not promote a stable system.
-
Another strange point. I've set my default route to WANORC in the gateways tab, but for some reason the WAN ip is showing as the default route in the route status display.
-
This is why you obviously can not access the system remotely.
I think some work needs to be done on the logic concerning the "system" route table and "policy" route tables. Losing the system default route table does not promote a stable system.
full ack, or we are missing anything..
-
Another strange point. I've set my default route to WANORC in the gateways tab, but for some reason the WAN ip is showing as the default route in the route status display.
Did you reboot after doing that? When I change default gw I need to reboot for changes to take effect..
BTW: Did you test that defaultgw down issue on 1.2x? How is it handled there?
-
@mxx:
Did you reboot after doing that? When I change default gw I need to reboot for changes to take effect..
BTW: Did you test that defaultgw down issue on 1.2x? How is it handled there?
No idea, never did multi-wan on 1.2. It doesnt have a multiple pptp wan option.
-
@mxx:
yes it does disappear
This is why you obviously can not access the system remotely.
No it's not. All WAN rules have routing information in them via pf's reply-to, you don't need any routing. There has been a whole lot of flux in the past couple weeks with interfaces and multi-WAN though, best to give it a few more days until all the fallout has been resolved (though I think the next snapshot should fix the last remaining issue, that remains to be seen).
-
@cmb:
No it's not. All WAN rules have routing information in them via pf's reply-to, you don't need any routing. There has been a whole lot of flux in the past couple weeks with interfaces and multi-WAN though, best to give it a few more days until all the fallout has been resolved (though I think the next snapshot should fix the last remaining issue, that remains to be seen).
That's what I was planning. Try one of the snapshots next week. See what has changed and see how it works in my environment.