Hello Jayapal,
Where is the nics tables, is it inside the router? Or in the CloudStack configuration? Thank you very much. On Tue, Jun 11, 2013 at 7:11 PM, Jayapal Reddy Uradi < jayapalreddy.ur...@citrix.com> wrote: > Hi, > > cmdline is having the correct config for eth2. > But router received command with interface eth3 instead of eth2, some > thing is wrong here. > > Please see what is device_id for the nic with the public ip in 'nics' > table. > > One possibility can be hypervisor might returning wrong device id for the > public interface. > > Thanks, > Jayapal > > > On 11-Jun-2013, at 4:12 PM, wq meng <wqm...@gmail.com> > wrote: > > > Hello, > > > > Here is the cmdline file and the logs from message file, there is > something > > tell that cloud setup eth3 with rules. > > > > http://pastebin.com/4WvpukKW > > > > > > Thank you very much. > > > > > > On Tue, Jun 11, 2013 at 6:11 PM, wq meng <wqm...@gmail.com> wrote: > > > >> Should be there is something not work as expected when some situation, > >> with this script ? > >> > >> /etc/init.d/cloud-early-config > >> > >> > >> Thank you very much. > >> > >> On Tue, Jun 11, 2013 at 5:59 PM, wq meng <wqm...@gmail.com> wrote: > >> > >>> Not sure why, is there a solution? > >>> > >>> Here is the new result, after create a new V-router. > >>> > >>> This time, the eth4 is disappear . But eth3 still there. > >>> > >>> Why??? > >>> > >>> http://pastebin.com/G0NjNCuA > >>> > >>> > >>> Thank you very much. > >>> > >>> > >>> On Tue, Jun 11, 2013 at 5:49 PM, Jayapal Reddy Uradi < > >>> jayapalreddy.ur...@citrix.com> wrote: > >>> > >>>> * packets are going out WITHOUT NAT and in reply the packets are not > >>>> reaching private ip address. > >>>> > >>>> Thanks > >>>> Jayapal > >>>> > >>>> On 11-Jun-2013, at 2:56 PM, Jayapal Reddy Uradi < > >>>> jayapalreddy.ur...@citrix.com> > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> If you observe in your router there 3 public interfaces with the same > >>>> IP address. > >>>>> The outbound/egress traffic is passing from eth0 to eth2. > >>>>> > >>>>> The iptables nat SNAT rule is not there on the eth2, but the rules > >>>> are on the eth3 and eth4 interface. > >>>>> So the packets are going out without NAT and in reply the packets are > >>>> not reaching back. > >>>>> > >>>>> So please check why you router has multiple SNAT ip addresses. > >>>>> Try destroying router and see the router is coming up one public > >>>> interface eth2 or not. > >>>>> > >>>>> 1. Interfaces with same ip address > >>>>> > >>>>> 1. > >>>>> eth2 Link encap:Ethernet HWaddr 06:74:78:00:00:a2 > >>>>> 2. > >>>>> inet addr:198.105.191.145 Bcast:198.105.191.255 > >>>> Mask:255.255.255.0 > >>>>> 3. > >>>>> 4. > >>>>> 5. > >>>>> eth3 Link encap:Ethernet HWaddr 06:6f:64:00:00:a2 > >>>>> 6. > >>>>> inet addr:198.105.191.145 Bcast:198.105.191.255 > >>>> Mask:255.255.255.0 > >>>>> 7. > >>>>> 8. > >>>>> 9. > >>>>> eth4 Link encap:Ethernet HWaddr 06:1e:c4:00:00:a2 > >>>>> 10. > >>>>> inet addr:198.105.191.145 Bcast:198.105.191.255 > >>>> Mask:255.255.255.0 > >>>>> 11. > >>>>> 12. > >>>>> > >>>>> 2. Here traffic is accepted on eth0 to eth2 (179 packets) > >>>>> 179 15036 FW_OUTBOUND all -- eth0 eth2 0.0.0.0/0 > >>>> 0.0.0.0/0 > >>>>> > >>>>> 3. In iptables nat table doesn't have the SNAT rule to nat the > traffic. > >>>>> > >>>>> 1. > >>>>> Chain POSTROUTING (policy ACCEPT 5 packets, 616 bytes) > >>>>> 2. > >>>>> pkts bytes target prot opt in out source > >>>> destination > >>>>> 3. > >>>>> 0 0 SNAT all -- * eth3 0.0.0.0/0 > >>>> 0.0.0.0/0 to:198.105.191.145 > >>>>> 4. > >>>>> 0 0 SNAT all -- * eth4 0.0.0.0/0 > >>>> 0.0.0.0/0 to:198.105.191.145 > >>>>> 5. > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Jayapal > >>>>> > >>>>> On 10-Jun-2013, at 11:16 PM, wq meng <wqm...@gmail.com<mailto: > >>>> wqm...@gmail.com>> wrote: > >>>>> > >>>>> Hello Jayapal, > >>>>> > >>>>> Setup details is that only 1 PC, with 1 network interface. eth1. > >>>>> > >>>>> I add br0 to eth1, and br0:0 to eth1. br0 work as KVM tag for mgmt. > >>>>> add eth1.1200 as the public VLan, 1200 is public vlan tag, > >>>>> add eth1.1300 as the guest Vlan, 1300 is the guest vlan tag. > >>>>> add cloudVirBr1200 to eth1.1200, KVM tag for* public* is > >>>> cloudVirBr1200 > >>>>> add cloudVirBr1300 to eth1.1300, KVM tag for private is > cloudVirBr1300 > >>>>> > >>>>> Here is the IP ranges. > >>>>> http://pastebin.com/uZBpx0Lr > >>>>> > >>>>> Here is how the NIC and bridges configuration on the Computer. > >>>>> http://pastebin.com/86jRex72 > >>>>> > >>>>> Here is the result from the v-router. > >>>>> http://pastebin.com/dcDUuyP7 > >>>>> > >>>>> > >>>>> Thank you very much. > >>>>> > >>>>> > >>>>> On Mon, Jun 10, 2013 at 4:58 PM, Jayapal Reddy Uradi < > >>>>> jayapalreddy.ur...@citrix.com> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> In advanced zone you can use openVswitch. > >>>>> Please share setup details like hypervisor, public ip range. > >>>>> > >>>>> Did you deploy vm with default network offering ? > >>>>> > >>>>> Please share your below commands output on router via pastebin.com > >>>>> Iptables -L -nv > >>>>> Iptables -t nat -L -nv > >>>>> Iptables -t mangle -L -nv > >>>>> > >>>>> Ifconfig > >>>>> > >>>>> Lets figure out is there any problem in cloudstack configuration. > >>>>> > >>>>> Thanks, > >>>>> Jayapal > >>>>> -----Original Message----- > >>>>> From: wq meng [mailto:wqm...@gmail.com] > >>>>> Sent: Sunday, 9 June 2013 1:43 AM > >>>>> To: users@cloudstack.apache.org > >>>>> Subject: Re: allow outbound access by default on virtual routers > >>>>> > >>>>> Hello Jayapal, > >>>>> > >>>>> Seems the problem exist in CS4.1.0 too. > >>>>> > >>>>> And I have tried the same NAT rule, not work. > >>>>> iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth2 -j SNAT --to > >>>>> xxx.105.191.147 > >>>>> > >>>>> > >>>>> Should use OpenvSwich? Is the OpenvSwitch is recommend? > >>>>> > >>>>> > >>>>> Thanks > >>>>> > >>>>> > >>>>> On Sun, Jun 2, 2013 at 5:01 AM, wq meng <wqm...@gmail.com> wrote: > >>>>> > >>>>> Hello Jayapal, > >>>>> > >>>>> I add a iptables rule > >>>>> > >>>>> iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth2 -j SNAT --to > >>>>> xxx.105.191.147 > >>>>> > >>>>> And it seems works now. I can ping Google inside the Guest VM. > >>>>> > >>>>> > >>>>> Just a few questions, Why in my VR-VM, it have eth3, eth4? Where > >>>>> are they come from, in the interface file, there is not > configuration > >>>>> for eth3 and eth4 at all. > >>>>> > >>>>> Sometimes, I reboot the VR-VM, the eth4 is disappear, only left eth3, > >>>>> but as you can know, it still not work, As eth3 is not a NIC at all. > >>>>> > >>>>> Then maybe the VR-VM have some buggy scripts when the VR-VM start , > >>>>> and which mis-configuration the NICs and also the NAT rules for > >>>>> VRouter? > >>>>> > >>>>> > >>>>> As the CS4.1 will be release soon on Monday, I am not sure, if it > >>>>> need spend more time to look deep. > >>>>> > >>>>> Thank you very much. > >>>>> > >>>>> > >>>>> On Sat, Jun 1, 2013 at 6:38 PM, wq meng <wqm...@gmail.com> wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> Sorry for the delay, > >>>>> > >>>>> Here is the NAT table. Please check. > >>>>> The xxx.105.191.147 IP is the public IP for the VRouter-VM. > >>>>> > >>>>> root@r-6-VM:~# iptables -t nat -L -nv Chain PREROUTING (policy > ACCEPT > >>>>> 258 packets, 13822 bytes) > >>>>> pkts bytes target prot opt in out source > >>>>> destination > >>>>> > >>>>> Chain POSTROUTING (policy ACCEPT 4 packets, 532 bytes) > >>>>> pkts bytes target prot opt in out source > >>>>> destination > >>>>> 0 0 SNAT all -- * eth3 0.0.0.0/0 > >>>>> 0.0.0.0/0 to:xxx.105.191.147 > >>>>> 0 0 SNAT all -- * eth4 0.0.0.0/0 > >>>>> 0.0.0.0/0 to:xxx.105.191.147 > >>>>> > >>>>> Chain OUTPUT (policy ACCEPT 3 packets, 448 bytes) > >>>>> pkts bytes target prot opt in out source > >>>>> destination > >>>>> > >>>>> root@r-6-VM:~# > >>>>> > >>>>> > >>>>> Thanks a lot. > >>>>> > >>>>> > >>>>> On Mon, May 27, 2013 at 1:09 PM, Jayapal Reddy Uradi < > >>>>> jayapalreddy.ur...@citrix.com> wrote: > >>>>> > >>>>> From the packet captures on eth2, the vm IP seems to be not NATed. > >>>>> 13:39:41.991966 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, id > >>>>> 56879, seq 126, length 64 > >>>>> > >>>>> Can you also share iptables -t nat -L -nv output. > >>>>> > >>>>> Thanks, > >>>>> Jayapal > >>>>> > >>>>> -----Original Message----- > >>>>> From: wq meng [mailto:wqm...@gmail.com] > >>>>> Sent: Friday, 24 May 2013 7:13 PM > >>>>> To: users@cloudstack.apache.org > >>>>> Subject: Re: allow outbound access by default on virtual routers > >>>>> > >>>>> Hello Jayapal > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I ping google.com on the Guest VM, > >>>>> > >>>>> Here is the dump data from the router - VM. > >>>>> > >>>>> Please review. > >>>>> > >>>>> And the 2.*.2 is public IP, which I replace to the real ip. > >>>>> > >>>>> > >>>>> Thank you very much. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> root@r-7-VM:~# > >>>>> root@r-7-VM:~# tcpdump -i eth0 -nq > >>>>> tcpdump: verbose output suppressed, use -v or -vv for full > >>>>> protocol > >>>>> decode > >>>>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 > >>>>> bytes > >>>>> 13:38:52.979198 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 77, length 64 > >>>>> 13:38:53.979203 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 78, length 64 > >>>>> 13:38:54.979205 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 79, length 64 > >>>>> 13:38:55.978182 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 80, length 64 > >>>>> 13:38:56.979188 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 81, length 64 > >>>>> 13:38:57.979299 ARP, Request who-has 10.1.1.1 tell 10.1.1.4, > >>>>> length 28 > >>>>> 13:38:57.979307 ARP, Reply 10.1.1.1 is-at 02:00:00:b1:00:05, > >>>>> length 28 > >>>>> 13:38:57.979315 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 82, length 64 > >>>>> 13:38:58.979250 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 83, length 64 > >>>>> 13:38:59.979297 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 84, length 64 > >>>>> 13:39:00.979313 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 85, length 64 > >>>>> 13:39:01.978311 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 86, length 64 > >>>>> 13:39:02.979282 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 87, length 64 > >>>>> 13:39:03.979323 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 88, length 64 > >>>>> 13:39:04.979315 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 89, length 64 > >>>>> 13:39:05.979364 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 90, length 64 > >>>>> 13:39:06.979420 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 91, length 64 > >>>>> 13:39:07.978421 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 92, length 64 > >>>>> 13:39:08.978432 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 93, length 64 > >>>>> 13:39:09.979447 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 94, length 64 > >>>>> 13:39:10.979437 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 95, length 64 > >>>>> 13:39:11.979474 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 96, length 64 > >>>>> 13:39:12.979473 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 97, length 64 > >>>>> 13:39:13.978525 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 98, length 64 > >>>>> 13:39:14.978535 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 99, length 64 > >>>>> 13:39:15.979562 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 100, length 64 > >>>>> 13:39:16.979575 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 101, length 64 > >>>>> 13:39:17.979602 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 102, length 64 > >>>>> 13:39:18.979584 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 103, length 64 > >>>>> 13:39:19.988541 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 104, length 64 > >>>>> 13:39:20.988615 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 105, length 64 > >>>>> 13:39:21.988598 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 106, length 64 > >>>>> 13:39:22.989582 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 107, length 64 > >>>>> 13:39:23.989666 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 108, length 64 > >>>>> 13:39:24.989695 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 109, length 64 > >>>>> 13:39:25.989725 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 110, length 64 ^C > >>>>> 36 packets captured > >>>>> 36 packets received by filter > >>>>> 0 packets dropped by kernel > >>>>> root@r-7-VM:~# tcpdump -i eth2 -nq > >>>>> tcpdump: verbose output suppressed, use -v or -vv for full > >>>>> protocol > >>>>> decode > >>>>> listening on eth2, link-type EN10MB (Ethernet), capture size 65535 > >>>>> bytes > >>>>> 13:39:38.380208 ARP, Request who-has 2.*.2.22 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:38.982570 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:38.987877 ARP, Request who-has 2.*.2.35 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:38.991937 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 123, length 64 > >>>>> 13:39:39.194709 ARP, Request who-has 2.*.2.22 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:39.599296 ARP, Request who-has 2.*.2.35 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:39.904508 ARP, Request who-has 2.*.2.22 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:39.991931 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 124, length 64 > >>>>> 13:39:40.417287 ARP, Request who-has 2.*.2.35 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:40.730305 ARP, Request who-has 2.*.2.22 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:40.982552 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:40.991980 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 125, length 64 > >>>>> 13:39:41.337501 ARP, Request who-has 2.*.2.35 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:41.437224 ARP, Request who-has 2.*.2.22 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:41.991966 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 126, length 64 > >>>>> 13:39:42.903756 ARP, Request who-has 2.*.2.248 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:42.982539 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:42.992996 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 127, length 64 > >>>>> 13:39:43.682772 ARP, Request who-has 2.*.2.248 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:43.993009 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 128, length 64 > >>>>> 13:39:44.502714 ARP, Request who-has 2.*.2.248 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:44.509679 ARP, Request who-has 2.*.2.228 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:44.585413 ARP, Request who-has 2.*.2.70 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:44.982554 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:44.993017 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 129, length 64 > >>>>> 13:39:45.160097 ARP, Request who-has 2.*.2.53 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:45.215168 ARP, Request who-has 2.*.2.70 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:45.318277 ARP, Request who-has 2.*.2.228 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:45.325738 ARP, Request who-has 2.*.2.34 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:45.421375 ARP, Request who-has 2.*.2.248 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:45.826574 ARP, Request who-has 2.*.2.70 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:45.928821 ARP, Request who-has 2.*.2.228 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:45.930246 ARP, Request who-has 2.*.2.53 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:45.993039 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 130, length 64 > >>>>> 13:39:46.030400 ARP, Request who-has 2.*.2.248 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:46.031609 ARP, Request who-has 2.*.2.34 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:46.349636 ARP, Request who-has 2.*.2.3 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:46.439927 ARP, Request who-has 2.*.2.70 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:46.486265 ARP, Request who-has 2.*.2.32 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:46.541822 ARP, Request who-has 2.*.2.228 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:46.850884 ARP, Request who-has 2.*.2.53 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:46.952230 ARP, Request who-has 2.*.2.34 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:46.982553 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:46.993050 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 131, length 64 > >>>>> 13:39:47.051629 ARP, Request who-has 2.*.2.70 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:47.154197 ARP, Request who-has 2.*.2.228 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:47.155893 ARP, Request who-has 2.*.2.3 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:47.258228 ARP, Request who-has 2.*.2.32 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:47.459210 ARP, Request who-has 2.*.2.53 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:47.561218 ARP, Request who-has 2.*.2.34 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:47.970622 ARP, Request who-has 2.*.2.32 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:47.971612 ARP, Request who-has 2.*.2.3 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:47.993074 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 132, length 64 > >>>>> 13:39:48.380271 ARP, Request who-has 2.*.2.34 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:48.381173 ARP, Request who-has 2.*.2.53 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:48.581498 ARP, Request who-has 2.*.2.32 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:48.890259 ARP, Request who-has 2.*.2.3 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:48.982519 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:48.994081 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 133, length 64 > >>>>> 13:39:49.290934 ARP, Request who-has 2.*.2.42 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:49.302649 ARP, Request who-has 2.*.2.32 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:49.433752 ARP, Request who-has 2.*.2.116 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:49.812965 ARP, Request who-has 2.*.2.3 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:49.994099 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 134, length 64 > >>>>> 13:39:50.014695 ARP, Request who-has 2.*.2.42 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:50.118276 ARP, Request who-has 2.*.2.116 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:50.933507 ARP, Request who-has 2.*.2.116 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:50.934227 ARP, Request who-has 2.*.2.42 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:50.982526 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:50.994092 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 135, length 64 > >>>>> 13:39:51.643878 ARP, Request who-has 2.*.2.42 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:51.848044 ARP, Request who-has 2.*.2.116 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:51.994151 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 136, length 64 > >>>>> 13:39:52.452001 ARP, Request who-has 2.*.2.116 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:39:52.453417 ARP, Request who-has 2.*.2.42 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:39:52.982496 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:52.994150 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 137, length 64 > >>>>> 13:39:53.994171 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 138, length 64 > >>>>> 13:39:54.982573 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:54.994188 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 139, length 64 > >>>>> 13:39:55.995186 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 140, length 64 > >>>>> 13:39:56.982561 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:56.995215 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 141, length 64 > >>>>> 13:39:57.991661 ARP, Request who-has 2.*.2.1 tell 2.*.2.25, length > >>>>> 28 > >>>>> 13:39:57.992092 ARP, Reply 2.*.2.1 is-at 5c:5e:ab:da:b9:c0, length > >>>>> 42 > >>>>> 13:39:57.995220 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 142, length 64 > >>>>> 13:39:58.982566 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:39:58.995244 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 143, length 64 > >>>>> 13:39:59.995280 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 144, length 64 > >>>>> 13:40:00.417613 ARP, Request who-has 2.*.2.4 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:00.982547 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:40:00.995274 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 145, length 64 > >>>>> 13:40:01.170853 ARP, Request who-has 2.*.2.4 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:01.996303 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 146, length 64 > >>>>> 13:40:02.074725 ARP, Request who-has 2.*.2.4 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:02.359140 ARP, Request who-has 2.*.2.161 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:40:02.982500 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:40:02.985123 ARP, Request who-has 2.*.2.4 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:02.996303 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 147, length 64 > >>>>> 13:40:03.186378 ARP, Request who-has 2.*.2.161 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:40:03.417268 ARP, Request who-has 2.*.2.20 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:03.699414 ARP, Request who-has 2.*.2.4 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:03.996329 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 148, length 64 > >>>>> 13:40:03.998677 ARP, Request who-has 2.*.2.161 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:40:04.301363 ARP, Request who-has 2.*.2.20 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:04.432828 ARP, Request who-has 2.*.2.115 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:40:04.435467 ARP, Request who-has 2.*.2.23 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:04.820262 ARP, Request who-has 2.*.2.161 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:40:04.920378 ARP, Request who-has 2.*.2.20 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:04.982690 STP 802.1d, Config, Flags [none], bridge-id > >>>>> 8000.00:25:90:a4:98:3e.8004, length 35 > >>>>> 13:40:04.996336 IP 10.1.1.4 > 74.125.224.228: ICMP echo request, > >>>>> id > >>>>> 56879, > >>>>> seq 149, length 64 > >>>>> 13:40:05.124674 ARP, Request who-has 2.*.2.23 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:05.124678 ARP, Request who-has 2.*.2.115 tell 2.*.2.1, > >>>>> length 42 > >>>>> 13:40:05.399662 ARP, Request who-has 2.*.2.12 tell 2.*.2.1, length > >>>>> 42 > >>>>> 13:40:05.429940 ARP, Request who-has 2.*.2.161 tell 2.*.2.1, > >>>>> length 42 > >>>>> ^C > >>>>> 115 packets captured > >>>>> 115 packets received by filter > >>>>> 0 packets dropped by kernel > >>>>> root@r-7-VM:~# > >>>>> > >>>>> > >>>>> On Fri, May 24, 2013 at 12:55 PM, Jayapal Reddy Uradi > >>>>> <jayapalreddy.ur...@citrix.com> wrote: > >>>>> Iptables rules are looking fine. > >>>>> Can you please do the following. > >>>>> 1. ping google.com from vm > >>>>> 2. run the tcpdump command on the router eth0, eth2 and see the > >>>>> packets are reaching to guest interface > >>>>> tcpdump -i eth0 -nq > >>>>> tcpdump -i eth2 -nq > >>>>> > >>>>> If guest vm icmp packets are not reaching to eth0 and eth2 then > >>>>> there is > >>>>> issue in your network setup. > >>>>> > >>>>> Thanks, > >>>>> Jayapal > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: wq meng [mailto:wqm...@gmail.com] > >>>>> Sent: Friday, 24 May 2013 1:27 AM > >>>>> To: users@cloudstack.apache.org > >>>>> Subject: Re: allow outbound access by default on virtual > >>>>> routers > >>>>> > >>>>> Hello, > >>>>> > >>>>> Have you tried this and get this to work? > >>>>> > >>>>> I think I have the same problem just can not get the Guest VM > >>>>> to access outbound by the V-router vm. > >>>>> > >>>>> my guest NIC is eth0, the public NIC is eth2. > >>>>> > >>>>> Here is the default rules in the Router VM. How to apply the > >>>>> rules to get the Guest VM can access outbound? > >>>>> > >>>>> Could you help me to show how? I have tried many times, just > >>>>> no > >>>>> luck of > >>>>> it. > >>>>> > >>>>> Thank you very much. > >>>>> > >>>>> > >>>>> root@r-7-VM:~# cat /etc/iptables/rules > >>>>> > >>>>> > >>>>> # Licensed to the Apache Software Foundation (ASF) under one # > >>>>> or more contributor license agreements. See the NOTICE file # > >>>>> distributed with this work for additional information # > >>>>> regarding copyright ownership. The ASF licenses this file # to > >>>>> you under the Apache License, Version 2.0 (the # "License"); > >>>>> you may not use this > >>>>> file > >>>>> except in compliance # with the License. > >>>>> You may obtain a copy of the License at # > >>>>> # http://www.apache.org/licenses/LICENSE-2.0 > >>>>> # > >>>>> # Unless required by applicable law or agreed to in writing, # > >>>>> software distributed under the License is distributed on an # > >>>>> "AS > >>>>> IS" > >>>>> BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY # KIND, > >>>>> either > >>>>> express or implied. > >>>>> See the License for the # specific language governing > >>>>> permissions > >>>>> and > >>>>> limitations # under the License. > >>>>> > >>>>> *nat > >>>>> :PREROUTING ACCEPT [0:0] > >>>>> :POSTROUTING ACCEPT [0:0] > >>>>> :OUTPUT ACCEPT [0:0] > >>>>> COMMIT > >>>>> *filter > >>>>> :INPUT DROP [0:0] > >>>>> :FORWARD DROP [0:0] > >>>>> :OUTPUT ACCEPT [0:0] > >>>>> -A INPUT -d 224.0.0.18/32 -j ACCEPT -A INPUT -d 225.0.0.50/32 > >>>>> -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED > >>>>> -j ACCEPT -A INPUT -i > >>>>> eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i > >>>>> eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p > >>>>> icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p udp > >>>>> -m udp --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp > >>>>> --dport 53 -j ACCEPT -A INPUT -i eth1 -p tcp -m state --state > >>>>> NEW --dport 3922 -j ACCEPT -A INPUT -i eth0 -p tcp -m state -- > >>>>> state NEW --dport 8080 -j ACCEPT -A INPUT -i eth0 -p tcp -m > >>>>> state --state NEW --dport 80 -j ACCEPT -A FORWARD -i eth0 -o > >>>>> eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD > >>>>> -i eth0 -o eth2 -j ACCEPT > >>>>> -A > >>>>> FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j > >>>>> ACCEPT -A FORWARD -i eth0 -o eth0 -m state --state NEW -j > >>>>> ACCEPT -A FORWARD -i > >>>>> eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT > >>>>> COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] > >>>>> :FORWARD > >>>>> ACCEPT > >>>>> [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A > >>>>> PREROUTING > >>>>> -m > >>>>> state --state ESTABLISHED,RELATED -j CONNMARK -- restore-mark > >>>>> -A POSTROUTING -p udp --dport bootpc -j CHECKSUM -- > >>>>> checksum-fill > >>>>> COMMIT > >>>>> > >>>>> > >>>>> root@r-7-VM:~# ifconfig > >>>>> > >>>>> > >>>>> On Mon, May 20, 2013 at 5:29 PM, Jayapal Reddy Uradi > >>>>> <jayapalreddy.ur...@citrix.com> wrote: > >>>>> > >>>>> Currently we don't have the configurable option. > >>>>> > >>>>> 1. You can add egress rule on network with protocol 'all' to > >>>>> allow all > >>>>> outbound traffic once the network is created. > >>>>> > >>>>> 2. If you want to allow traffic by default when ever router > >>>>> is created One work around will be add the below line into > >>>>> the iptables-router file > >>>>> after the this line -I FW_OUTBOUND -m state --state > >>>>> RELATED,ESTABLISHED > >>>>> -j ACCEPT > >>>>> > >>>>> -A FW_OUTBOUND -j ACCEPT > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Jayapal > >>>>> > >>>>> > >>>>> On 20-May-2013, at 2:18 PM, Len Bellemore > >>>>> <len.bellem...@controlcircle.com> wrote: > >>>>> > >>>>> Hi Guys > >>>>> > >>>>> Anyone know if it's possible to change some of the default > >>>>> options > >>>>> on a > >>>>> virtual router, so that every time it gets created it has > >>>>> particular rules? > >>>>> > >>>>> My main issue is that I want to allow outbound access by > >>>>> default to every > >>>>> account. > >>>>> > >>>>> Thanks > >>>>> Len > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >> > >
