cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)
Date Sat, 22 Jul 2017 08:54:01 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16097179#comment-16097179
] 

ASF subversion and git services commented on CLOUDSTACK-9838:
-------------------------------------------------------------

Commit aa8a721c393347b2624184d6ed04e1ede7ed38a6 in cloudstack's branch refs/heads/4.9 from
[~rohit.yadav@shapeblue.com]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=aa8a721 ]

CLOUDSTACK-9838: Allow ingress traffic between guest VMs via snat IPs

This enables the firewall/mangle tables rules to ACCEPT instead of RETURN, which
is the same behaviour as observed in ACS 4.5. By accepting the traffic, guest
VMs will be able to communicate tcp traffic between each other over snat public
IPs.

Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>


> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP
IPs (normal VR)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9838
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>            Reporter: Paul Angus
>            Assignee: Rohit Yadav
>            Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot communicate
with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN happens
later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target     prot opt in     out     source               destination
>     0     0 ACCEPT     all  --  any    any     anywhere             anywhere        
    state RELATED,ESTABLISHED
>     0     0 RETURN     icmp --  any    any     anywhere             anywhere        
    icmptype 8 code 0
>     0     0 RETURN     tcp  --  any    any     anywhere             anywhere        
    tcp dpt:http
>     0     0 DROP       all  --  any    any     anywhere             anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so inspections
don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target     prot opt in     out     source               destination
>     0     0 ACCEPT     icmp --  any    any     anywhere             anywhere        
    icmptype 8 code 0
>    39  3002 RETURN     tcp  --  any    any     anywhere             anywhere        
    tcp dpt:http
>  4921 4906K ACCEPT     all  --  any    any     anywhere             anywhere        
    state RELATED,ESTABLISHED
>   397 40700 DROP       all  --  any    any     anywhere             anywhere
> moving
>  4921 4906K ACCEPT     all  --  any    any     anywhere             anywhere        
    state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle table



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message