See the following example:
---
------+----------------- external network 192.168.10.0/24
|
| 192.168.10.10
+---+---+
| r1 | routes [{nexthop: 10.0.0.2, destination: 20.0.0.0/24}]
+---+---+
| 10.0.0.1
|
-----+-----+----------- tenant network1 10.0.0.0/24 (gw: 10.0.0.1)
|
| 10.0.0.2
+---+---+
| r2 | routes [{nexthop: 10.0.0.1, destination: 0.0.0.0/0}]
+---+---+
| 20.0.0.1
|
-----------+------------ tenant network2 20.0.0.0/24 (gw: 20.0.0.1)
---
Users want to access external network from tenant network2 using default SNAT but can't access.
(tenant network2 is connected to r1 indirectly and set routes properly.)
Users can access external network only from tenant network1 (it is directly connected to r1) currently.
I think it is a bug since this restriction is unnecessary.
It is easy to fix. How about this ?
---
diff --git a/neutron/agent/l3_agent.py b/neutron/agent/l3_agent.py
index ff8ad47..097fa36 100644
--- a/neutron/agent/l3_agent.py
+++ b/neutron/agent/l3_agent.py
@@ -1445,9 +1445,8 @@ class L3NATAgent(firewall_l3_agent.FWaaSL3AgentRpcCallback,
rules = [('POSTROUTING', '! -i %(interface_name)s '
'! -o %(interface_name)s -m conntrack ! '
'--ctstate DNAT -j ACCEPT' %
- {'interface_name': interface_name})]
- for cidr in internal_cidrs:
- rules.extend(self.internal_network_nat_rules(ex_gw_ip, cidr))
+ {'interface_name': interface_name}),
+ ('snat', '-j SNAT --to-source %s' % ex_gw_ip)]
return rules
def _snat_redirect_add(self, ri, gateway, sn_port, sn_int):
@@ -1560,11 +1559,6 @@ class L3NATAgent(firewall_l3_agent.FWaaSL3AgentRpcCallback,
self.driver.unplug(interface_name, namespace=ri.ns_name,
prefix=INTERNAL_DEV_PREFIX)
- def internal_network_nat_rules(self, ex_gw_ip, internal_cidr):
- rules = [('snat', '-s %s -j SNAT --to-source %s' %
- (internal_cidr, ex_gw_ip))]
- return rules
-
def _create_agent_gateway_port(self, ri, network_id):
"""Create Floating IP gateway port.
---
I think this is the limitation from the initial commit of l3-agent, and it sounds reasonable to relax this limitation to provide more flexibility of the topology of virtual networks.
Regarding the solution mentioned in the bug report,
+ ('snat', '-j SNAT --to-source %s' % ex_gw_ip)]
seems a bit dangerous because this rule tries to apply SNAT for all traffic. Generally speaking we should have more strict match rule to avoid any side effect.
I have not checked the detail behavior of SNAT rules in l3-agent, but it is worth investigated what traffic matches the SNAT rule. IMHO it is better to examine from what interfaces traffic come or similar things. I am afraid traffic from local or traffic handled by OpenSwan are affected by the rule.