Hi,

If you still have issue, please file a bug.
Please mention the reproducing steps clearly, also attach the all the required 
logs (management server logs, router logs, iptables logs and required DB tables 
data).

Thanks,
Jayapal


On 14-Jun-2013, at 4:59 AM, wq meng <wqm...@gmail.com> wrote:

> Hello Jayapal
> 
> We still not have idea on how the problem?
> 
> Seems I am not alone, still have others have the same problem with  KVM ,
> advanced network.
> 
> 
> Thank you very much.
> 
> 
> On Wed, Jun 12, 2013 at 5:11 AM, wq meng <wqm...@gmail.com> wrote:
> 
>> Hello Jayapal
>> 
>> Here is the nics
>> 
>> http://pastebin.com/8Q4E09uj
>> 
>> I can not find anything odd here.
>> 
>> Is there has any problem?
>> 
>> 
>> Thank you very much.
>> 
>> 
>> 
>> 
>> On Tue, Jun 11, 2013 at 8:55 PM, Jayapal Reddy Uradi <
>> jayapalreddy.ur...@citrix.com> wrote:
>> 
>>> Check in cloudstack management server  mysql database .
>>> 
>>> Thanks,
>>> Jayapal
>>>> -----Original Message-----
>>>> From: wq meng [mailto:wqm...@gmail.com]
>>>> Sent: Tuesday, 11 June 2013 5:10 PM
>>>> To: users@cloudstack.apache.org
>>>> Subject: Re: allow outbound access by default on virtual routers
>>>> 
>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>> 
>> 

Reply via email to