[
https://issues.apache.org/jira/browse/CLOUDSTACK-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053173#comment-15053173
]
ASF GitHub Bot commented on CLOUDSTACK-9143:
--------------------------------------------
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1214#issuecomment-164013935
code lgtm and @remibergsma ran the regression tests. If people complain we
have a a regression to decide on but it seems ok to me.
> Setup routes for RFC 1918 ip space
> ----------------------------------
>
> Key: CLOUDSTACK-9143
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9143
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
> Reporter: Remi Bergsma
> Assignee: Remi Bergsma
> Priority: Critical
> Fix For: 4.7.0
>
>
> Setup general route for RFC 1918 space, as otherwise it will be sent to the
> public gateway and likely to be dropped (internet providers do not route ip
> space that is meant for internal use). More specific routes that may be set
> have preference over this generic routes so this works even with private
> ranges used for public ip space (as shown below).
> When using an internal DNS server some hosts may resolve to an RFC 1918 ip
> address. The SSVM has a default gw to public so if it has no route for this
> ip address space, it will not work. This PR makes generic RFC 1918 (so all
> internal ip adresses like 10.0.0.10 etc) to the local management gateway.
> This makes them reachable. Without this fix, it is sent upstream and it is
> dropped there.
> Should there be a more generic route (smaller prefix), this has preference
> over the generic routes.
> Example in my dev environment:
> ```
> root@v-1-VM:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 192.168.23.1 0.0.0.0 UG 0 0 0 eth2
> 10.0.0.0 192.168.22.1 255.0.0.0 UG 0 0 0 eth1
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
> 172.16.0.0 192.168.22.1 255.240.0.0 UG 0 0 0 eth1
> 192.168.0.0 192.168.22.1 255.255.0.0 UG 0 0 0 eth1
> 192.168.22.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 192.168.23.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
> ```
> Route `192.168.0.0/16` goes via `eth1` but `192.168.23.0/24` is more specific
> and has preference and goes via `eth2`. It works:
> ```
> root@v-1-VM:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 48 data bytes
> 56 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=7.179 ms
> ^C--- 8.8.8.8 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 7.179/7.179/7.179/0.000 ms
> ```
> This solves a lot of the 'internal resolving' issues we face.
> When the public ip address is RFC1918 itself, we do not set the routes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
