Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A0F8818907 for ; Fri, 11 Dec 2015 10:02:33 +0000 (UTC) Received: (qmail 84780 invoked by uid 500); 11 Dec 2015 10:02:33 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 84723 invoked by uid 500); 11 Dec 2015 10:02:33 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 84707 invoked by uid 99); 11 Dec 2015 10:02:32 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Dec 2015 10:02:32 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id B4149E01F2; Fri, 11 Dec 2015 10:02:32 +0000 (UTC) From: remibergsma To: dev@cloudstack.apache.org Reply-To: dev@cloudstack.apache.org References: In-Reply-To: Subject: [GitHub] cloudstack pull request: Setup routes for RFC 1918 ip space Content-Type: text/plain Message-Id: <20151211100232.B4149E01F2@git1-us-west.apache.org> Date: Fri, 11 Dec 2015 10:02:32 +0000 (UTC) Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1214#issuecomment-163895685 @terbolous I appreciate your worries, and I'll try to explain why I think there is nothing to worry about. Right now, everything that has no specific route will go to the default gateway. The default gateway is the gateway of the public interface. So, if the internal DNS server resolved `remi.nl` to `10.0.0.1` the systemvm will send that to the gateway of the public network, which will drop it because it won't accept RFC1918 space. With this change, it is routed to the internal gateway instead which may or may not be able to reach it. If it can, this is a win. If it cannot, we have the same situation as we have now. I tested the console and that works fine. The reason for this is, that routing in Linux takes specific routes over more generic ones. If I set `10.0.0.0/8` to the internal gateway, and `10.0.0.1/32` or `10.1.0.0/24` to another interface (because it may be the secondary storage network or whatever) then this `/24` is more specific than the `/8`. The routes I added act like a `catch-all` to try the internal gateway before giving up. Hope this helps! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastructure@apache.org or file a JIRA ticket with INFRA. ---