| Anonymous | Login | 2024-12-22 11:01 MST |
| Main | My View | View Issues | Change Log | Roadmap | Repositories |
| View Revisions: Issue #993 | [ Back to Issue ] | ||
| Summary | 0000993: Access to local WAN network should be permitted even when WAN is offline | ||
| Revision | 2013-02-25 20:46 by user2 | ||
| Additional Information | In ClearOS 5.x, the following workaround is available - add masquerading to all WAN interfaces in /etc/rc.d/rc.firewall.local. Continuing with our example, this would be: /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE /sbin/iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE |
||
| Revision | 2013-02-25 20:49 by user2 | ||
| Additional Information | In ClearOS 5.x, the following workaround is available - add masquerading to all WAN interfaces in /etc/rc.d/rc.firewall.local. Continuing with our example, this would be: /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE /sbin/iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE In ClearOS 6, additional work is required. The individual routing tables for external interfaces (first loop in RunMultipath()) interferes with the above workaround. To investigate. |
||
| Revision | 2013-02-25 20:46 by user2 | ||
| Description | In some circumstances, access equipment directly connected to a WAN is necessary even when offline. Consider example: - WAN1 / eth1 @ 192.168.55.6 with gateway 192.168.55.1 - WAN2 / eth2 @ 10.0.0.6 with gateway 10.0.0.1 If WAN1 goes offline, it should be possible to still access the gateway at 192.168.55.1. Currently, that access fails. |
||
| Revision | 2013-02-25 20:56 by user2 | ||
| Description | In some circumstances, access equipment directly connected to a WAN is necessary even when offline. Consider example: - WAN1 / eth1 @ 2.2.2.2 with gateway 2.2.2.1 - WAN2 / eth2 @ 3.3.3.3 with gateway 3.3.3.1 - LAN / eth3 @ 192.168.99.x If WAN1 goes offline, it should be possible to still access the gateway at 2.2.2.1. Currently, that access fails due to masquerading/routing. When WAN1 is offline, traffic from the LAN (192.168.99.x) to 2.2.2.1 is not masqueraded. When the 2.2.2.1 system sends the reply, it will sent it out its default gateway (not back to 2.2.2.2). |
||