In Multi ISP env having a static route on the FW itself impies that the remote host is forced to communicate over the same path that the static route indicates ?? In other words, If ip route add 173.194.39.212/32 via .... ISP1 is placed on the fw, and provided that there is static ip prefix vv.vv.vv.vv/nn for ISP1 and xx.xx.xx.xx/n for ISP2 assigned in the DMZ zone. Is it possible for the remote 173.194.39.212 to access a host in the dmz over the ISP2 link besides the MARK technique using of cource the ISP2 assigned ip address space? Thanks in advance Harry. ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
On 10/11/2013 4:52 AM, HL wrote:> In Multi ISP env having a static route on the FW itself impies that the > remote host is forced to communicate over the same path that the static > route indicates ?? > In other words, > If ip route add 173.194.39.212/32 via .... ISP1 is placed on the fw, > and > provided that there is static ip prefix vv.vv.vv.vv/nn for ISP1 and > xx.xx.xx.xx/n for ISP2 assigned in the DMZ zone. > Is it possible for the remote 173.194.39.212 to access a host in the dmz > over the ISP2 link besides the MARK technique using of cource the ISP2 > assigned ip address space?The remote host should still be able to connect over the other provider. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
On 10/11/2013 9:59 AM, Tom Eastep wrote:> On 10/11/2013 4:52 AM, HL wrote: >> In Multi ISP env having a static route on the FW itself impies that the >> remote host is forced to communicate over the same path that the static >> route indicates ?? >> In other words, >> If ip route add 173.194.39.212/32 via .... ISP1 is placed on the fw, >> and >> provided that there is static ip prefix vv.vv.vv.vv/nn for ISP1 and >> xx.xx.xx.xx/n for ISP2 assigned in the DMZ zone. >> Is it possible for the remote 173.194.39.212 to access a host in the dmz >> over the ISP2 link besides the MARK technique using of cource the ISP2 >> assigned ip address space? > > The remote host should still be able to connect over the other provider. >Let me restate that -- is should be able to connect via the other ISP if USE_DEFAULT_RT=No. It will not be able to use the other ISP if USE_DEFAULT_RT=Yes. In the latter case, the ''main'' routing table is traversed before packet marks are consulted. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk