asymmetric routes/security concerns/Fortinet

Fri Jan 7 20:24:41 UTC 2011

On Fri, Jan 07, 2011 at 03:13:02PM -0500, Greg Whynott said:
  >Thanks Ken,
  >
  >Some good stuff there,  thanks.
  >
  >Since my original email,  i think i've come up with a partial solution not requiring the far end's involvement.     If not,  at least it would get us into a better position to utilize the ORION network when possible.   We peer over a L2 tunnel with a router down in the states threw one of our ISP's 10G links,  I'm going to see if ORION will do the same with us.  This would allow us to establish a BGP session directly with the ORION router,  then I could use the localpref options, which may help.
  >
  >this problem is intermitting,  most of the time things are fine.    doing the above isn't going to help if path/route conditions change,  but at least we'll have done all we could within reason and have a proper config.
  >
  >I didn't consider the reasons you mentioned related to 'fail fast', that does make a lot of sense.   this is not the reason they claim this policy is in place,  it is for security reasons.
  >
  >we access ORION via GTAnet,  they are within/part of/something to do with the UoT,  and we are across the street.

Intermittent sounds exactly like what's happening - and alternate routes are
being chosen when the main link or peering session is down. And their firewall
isnt liking the alternate route and blocking packets. (oddly if their policy
is simple enough, you sending packets to them also across the open internet
so you both are using it to eachother, might make things work - with a further
reduction in (perceived?) security. :)

Yes, peering directly with ORION would allow you some control of outgoing
packets if that's the issue - ie the issue is you sending via open internet.

But if the issue is you receiving via open internet (ie the far side is
sending via open internet because their ORION routes are not being preferred
to you due to outtage, etc), then you'll have to work with them on their side
of the issue. Localpref and other big hammer approaches to preferences are
effective but indelicate, and only work on outgoing traffic. Engineering
incoming traffic is a black art (there are several vendors that will sell you
gear and access to help you of course :)

If you are going through an upstream that is also on ORION, their concerns for
routing to your target should be convergent with yours. Im suspecting that the
issue is at the far end with their firewalling policy and link/session, which
are harder for you to fix directly. You could also get a lan extension
between your site and theirs directly if you wanted to peer with that entity
directly, if signficant/frequent valuable traffic between you is sufficient, and
you do not want it to ever pass over the open internet.

good luck.

/kc

  >
  >
  >take care,
  >greg
  >
  >
  >
  >
  >
  >
  >@Anthony Pardini <tony at pardini.org>
  >On Jan 7, 2011, at 2:45 PM, Anthony Pardini wrote:
  >
  >>   Firewalls aren't routers and pretty much all of them
  >> behave in the similar manner.
  >
  >
  >
  >oh!  thanks.  8)
  >
  >
  >
  >
  >
  >
  >
  >
  >
  >On Jan 7, 2011, at 2:37 PM, Ken Chase wrote:
  >>
  >> It sounds like the target site has a possible misconfiguration if this is a
  >> long term issue. If they're using the open internet to get back to you and not
  >> ORION (when your packets arrived from ORION-based connection), then something
  >> is misconfigured or down. The problem is a conflict in the way BGP works and
  >> how people assume it works :) BGP is designed to get packets to where they
  >> want to go, not drop them if they're going the wrong way.
  >
  >
  >--
  >
  >This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.

-- 
Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA
Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.