[jira] [Commented] (CLOUDSTACK-10346) Problem with NAT configuration and VMs not accessing each other via public IPs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639092#comment-16639092
]
ASF GitHub Bot commented on CLOUDSTACK-10346:
-
rhtyd commented on issue #2514: [CLOUDSTACK-10346] Problem with NAT
configuration and VMs not accessing each other via public IPs
URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-427210903
The basic tests of ingress/egress to/from user VMs to other user VMs using
public SNAT (attached) IP pass for me both when VMs were in (a) different tiers
in the same VPC, (b) across VPCs, (c) in the same tier. Packet marking in
4.11.2.0 is slightly changed to fix a bug where marking a packet with 0x0
failed in the new VR. Routing etc LGTM, I tested the latest 4.11 branch
(4.11.2.0 rc2 + two new commits not related to VR).
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem with NAT configuration and VMs not accessing each other via public IPs
> --
>
> Key: CLOUDSTACK-10346
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10346
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> When users create a VPC, and configure a NAT from a public IP to application
> in a VM. This VM(applications) are not accessible via public IP for other VMs
> in the same VPC.
>
> The problem is in the NAT table. If you take a closer look at rules, you will
> see something like:
> {code:java}
> -A PREROUTING -d publicIP/32 -i eth1 -p tcp -m tcp --dport 80 -j DNAT
> --to-destination internalIp:80
> {code}
> The problem is that according to this rule only packets coming via
> eth1(public interface), will be “redirected” to the internal IP. We need an
> extra entry to each one of the NAT configurations. For the presented rule, we
> would need something like:
> {code:java}
> -A PREROUTING -d publicIP/32 -i eth2 -p tcp -m tcp --dport 80 -j DNAT
> --to-destination internalIp:80
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10346) Problem with NAT configuration and VMs not accessing each other via public IPs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639093#comment-16639093
]
ASF GitHub Bot commented on CLOUDSTACK-10346:
-
rhtyd edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT
configuration and VMs not accessing each other via public IPs
URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-427210903
@izenk The basic tests of ingress/egress to/from user VMs to other user VMs
using public SNAT (attached) IP pass for me both when VMs were in (a) different
tiers in the same VPC, (b) across VPCs, (c) in the same tier. Packet marking in
4.11.2.0 is slightly changed to fix a bug where marking a packet with 0x0
failed in the new VR. Routing etc LGTM, I tested the latest 4.11 branch
(4.11.2.0 rc2 + two new commits not related to VR).
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem with NAT configuration and VMs not accessing each other via public IPs
> --
>
> Key: CLOUDSTACK-10346
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10346
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> When users create a VPC, and configure a NAT from a public IP to application
> in a VM. This VM(applications) are not accessible via public IP for other VMs
> in the same VPC.
>
> The problem is in the NAT table. If you take a closer look at rules, you will
> see something like:
> {code:java}
> -A PREROUTING -d publicIP/32 -i eth1 -p tcp -m tcp --dport 80 -j DNAT
> --to-destination internalIp:80
> {code}
> The problem is that according to this rule only packets coming via
> eth1(public interface), will be “redirected” to the internal IP. We need an
> extra entry to each one of the NAT configurations. For the presented rule, we
> would need something like:
> {code:java}
> -A PREROUTING -d publicIP/32 -i eth2 -p tcp -m tcp --dport 80 -j DNAT
> --to-destination internalIp:80
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10380) changing passwordenabled to true while guest vm is running causes unexpected passwordreset again in startvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639058#comment-16639058 ] ASF subversion and git services commented on CLOUDSTACK-10380: -- Commit fe10e684f9a172ac8b2a6af48a1ef5611622a850 in cloudstack's branch refs/heads/master from [~paulangus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=fe10e68 ] Merge pull request #2743 from nuagenetworks/bugfix/marvin_config_drive CLOUDSTACK-10380: Fix startvm giving another pw after pw reset > changing passwordenabled to true while guest vm is running causes unexpected > passwordreset again in startvm > --- > > Key: CLOUDSTACK-10380 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10380 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12, 4.11.1.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Major > > changing passwordenabled to true while guest vm is running causes > passwordreset again in startvm > Steps to reproduce: > # Template passwordenabled flag is set to false > # Start Vm > # Set template passwordenabled flag to true > # StopVm > # ResetPassword for Stopped Vm. Password is PasswordA. > # StartVm. Password is PasswordB. This should not happen!! > # SSH into VM only works with PasswordB. > Next steps are as expected. > # StopVm > # ResetPassword for Stopped Vm. Password is PasswordC. > # 1StartVm. No change in password. > # SSH into VM works with PasswordC. > This was found when > test/integration/plugins/nuagevsp/test_nuage_passwordreset.py started to fail > after merging of PR2651 [https://github.com/apache/cloudstack/pull/2651]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10380) changing passwordenabled to true while guest vm is running causes unexpected passwordreset again in startvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639057#comment-16639057 ] ASF subversion and git services commented on CLOUDSTACK-10380: -- Commit 604158220d894788e37d631119171051b50f1325 in cloudstack's branch refs/heads/master from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6041582 ] CLOUDSTACK-10380: Refactoring of test_configdrive > changing passwordenabled to true while guest vm is running causes unexpected > passwordreset again in startvm > --- > > Key: CLOUDSTACK-10380 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10380 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12, 4.11.1.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Major > > changing passwordenabled to true while guest vm is running causes > passwordreset again in startvm > Steps to reproduce: > # Template passwordenabled flag is set to false > # Start Vm > # Set template passwordenabled flag to true > # StopVm > # ResetPassword for Stopped Vm. Password is PasswordA. > # StartVm. Password is PasswordB. This should not happen!! > # SSH into VM only works with PasswordB. > Next steps are as expected. > # StopVm > # ResetPassword for Stopped Vm. Password is PasswordC. > # 1StartVm. No change in password. > # SSH into VM works with PasswordC. > This was found when > test/integration/plugins/nuagevsp/test_nuage_passwordreset.py started to fail > after merging of PR2651 [https://github.com/apache/cloudstack/pull/2651]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9974) VR got 4 nics instead of 3; public IP assigned on eth3 instead of eth2; SNAT not working
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638561#comment-16638561
]
Ran Huang commented on CLOUDSTACK-9974:
---
Greetings,
I have experienced the exact same issue for cloudstack v4.9.2 on Centos7.4
This occurs when using a tagged vlan for public network. If the public network
uses vlan://untagged instead then the issue does not occur.
The Linux bridge interface referenced by Libvirt, which is different for tagged
and untagged vlan, is used to decide if a new vif should be plugged into VR or
otherwise. In the case of tagged vlan, a new vif is plugged into VR, when it
should not.
Destroying router and restarting network does not fix this issue.
regards.
> VR got 4 nics instead of 3; public IP assigned on eth3 instead of eth2; SNAT
> not working
>
>
> Key: CLOUDSTACK-9974
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9974
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: cloudstack-agent, KVM, Virtual Router
>Affects Versions: 4.9.2.0
> Environment: Cloudstack 4.9.2.0
> 1 cluster Ubuntu 16.04 with KVM
> 1 cluster XenServer 6.5SP1
> Zone with Advanced Network
>Reporter: Francois Scheurer
>Priority: Critical
>
> Dear Cloudstack contributors
> We are currently testing CS 4.9.2 with XenServer (6.5) and KVM (Ubuntu 16.04).
> We noticed that the VR on KVM are created with 4 nics (eth0-eth3) instead of
> 3.
> The bad effect is that SNAT is not working, so the VM's cannot access
> internet...
> As you can see, the public ip 217.71.92.215 ha an SNAT on eth2 but is
> allocated to eth3:
> root@r-4862-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 02:00:70:65:00:02 brd ff:ff:ff:ff:ff:ff
> inet 172.16.0.1/24 brd 172.16.0.255 scope global eth0
> 3: eth1: mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 0e:00:a9:fe:03:04 brd ff:ff:ff:ff:ff:ff
> inet 169.254.3.4/16 brd 169.254.255.255 scope global eth1
> 4: eth2: mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 06:29:76:00:02:45 brd ff:ff:ff:ff:ff:ff
> 5: eth3: mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> link/ether 06:1f:96:00:02:45 brd ff:ff:ff:ff:ff:ff
> inet 217.71.92.215/27 brd 217.71.92.223 scope global eth3
> root@r-4862-VM:~# iptables -t nat -L -n -v
> Chain PREROUTING (policy ACCEPT 45661 packets, 3361K bytes)
> pkts bytes target prot opt in out source
> destination
> Chain INPUT (policy ACCEPT 12476 packets, 844K bytes)
> pkts bytes target prot opt in out source
> destination
> Chain OUTPUT (policy ACCEPT 19244 packets, 1285K bytes)
> pkts bytes target prot opt in out source
> destination
> Chain POSTROUTING (policy ACCEPT 19240 packets, 1284K bytes)
> pkts bytes target prot opt in out source
> destination
> 4 304 SNAT all -- * eth20.0.0.0/0
> 0.0.0.0/0to:217.71.92.215
> eth3 should not exist at all...
> Rebooting the VR several sometimes "fixes" the issue and allocates the public
> ip to eth2, but eth3 still exists.
> Let's look why eth3 is created:
> root@r-4862-VM:~# grep -r eth3 /etc
> /etc/cloudstack/ips.json:"eth3": [
> /etc/cloudstack/ips.json:"device": "eth3",
> /etc/iptables/iptables-secstorage:-A INPUT -i eth3 -m state --state
> RELATED,ESTABLISHED -j ACCEPT
> /etc/iptables/router_rules.v4:-A PREROUTING -i eth3 -m state --state
> NEW -j CONNMARK --set-xmark 0x3/0x
> /etc/iptables/router_rules.v4:-A INPUT -i eth3 -m state --state
> RELATED,ESTABLISHED -j ACCEPT
> /etc/iptables/router_rules.v4:-A FORWARD -i eth3 -o eth0 -m state
> --state RELATED,ESTABLISHED -j ACCEPT
> /etc/iptables/router_rules.v4:-A FORWARD -i eth0 -o eth3 -j
> FW_OUTBOUND
> /etc/iproute2/rt_tables:3 Table_eth3
> /etc/init.d/cloud-early-config:echo "auto eth3" >>
> /etc/network/interfaces
> /etc/init.d/cloud-early-config:[ -n "$MTU" ] && ifconfig eth3 mtu
> $MTU && echo " mtu $MTU" >> /etc/network/interfaces
> root@r-4862-VM:~# cat /etc/cloudstack/ips.json
> {
> "eth0": [
> {
>
