cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (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 Fri, 07 Apr 2017 11:48:41 GMT

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

ASF GitHub Bot commented on CLOUDSTACK-9838:
--------------------------------------------

Github user blueorangutan commented on the issue:

    https://github.com/apache/cloudstack/pull/2034
  
    @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make
progress.


> 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
>            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.3.15#6346)

Mime
View raw message