[
https://issues.apache.org/jira/browse/CLOUDSTACK-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053180#comment-15053180
]
ASF subversion and git services commented on CLOUDSTACK-9143:
-------------------------------------------------------------
Commit c9985e96a5446395f402faccd422935d24b7c933 in cloudstack's branch
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c9985e9 ]
Merge pull request #1214 from remibergsma/rfc1918_route
CLOUDSTACK-9143 Setup routes for RFC 1918 ip spaceSetup 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.
* pr/1214:
Setup routes for RFC 1918 ip space
Signed-off-by: Remi Bergsma <[email protected]>
> 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)
