Hi Noel, Could you put the IP tables on pastebin? GMail has collapsed the lines horrifically. Have you also tried a tcpdump on both interfaces on the VR? tcpdump -i eth0 <--- Or whatever it may be called
I would expect worse connectivity if it was a pure NAT issue, but I will review the tables later. Thanks, Marty On Sat, Sep 14, 2013 at 5:55 PM, Noel Kendall <[email protected]>wrote: > Not seeing return packets on VR. Suspect, therefore, that SNAT is fouled > up in some way.I have been doing wget to from guest, can see the outgoing > request fine, both in the guest andthe VR. > Could it be that the SNAT table entries from the 10.11.0.0/16 subnet to > dpt www are interfering withthe SNAT to public ip?? (wild guess) - not an > iptables expert by any stretch of the imagination > 67.xxx.xxx.56 is the guest public IP10.11.79.178 is the guest IP on guest > network > iptables _L -t nat on the VR shows... > Chain PREROUTING (policy ACCEPT)target prot opt source > destination DNAT tcp -- anywhere anywhere > tcp dpt:domain to:10.11.0.1 DNAT tcp -- anywhere > 67.xxx.xxx.56 tcp dpt:www to:10.11.79.178:80 DNAT tcp -- > anywhere 67.xxx.xxx.56 tcp dpt:www to:10.11.79.178:80DNAT > tcp -- anywhere 67.xxx.xxx.56 tcp dpt:https > to:10.11.79.178:443 DNAT tcp -- anywhere > 67.xxx.xxx.56 tcp dpt:https to:10.11.79.178:443 DNAT tcp -- > anywhere 67.xxx.xxx.56 tcp dpt:ssh to:10.11.79.178:22DNAT > tcp -- anywhere 67.xxx.xxx.56 tcp dpt:ssh > to:10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 > tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > 67.xxx.xxx.56 tcp dpt:ftp to:10.11.79.178:21 DNAT tcp > -- anywhere 67.xxx.xxx.56 tcp dpt:5901 to: > 10.11.79.178:5901 DNAT tcp -- anywhere 67.xxx.xxx.56 > tcp dpt:5901 to:10.11.79.178:5901 > Chain POSTROUTING (policy ACCEPT)target prot opt source > destination SNAT all -- anywhere anywhere > to:67.xxx.xxx.56 SNAT all -- anywhere anywhere > to:67.xxx.xxx.56 SNAT all -- anywhere > anywhere to:67.xxx.xxx.56 SNAT all -- anywhere > anywhere to:67.xxx.xxx.56 SNAT all -- anywhere > anywhere to:67.xxx.xxx.56SNAT all -- anywhere > anywhere to:67.xxx.xxx.56 SNAT all -- anywhere > anywhere to:67.xxx.xxx.56 SNAT all -- anywhere > anywhere to:67.xxx.xxx.56 SNAT tcp -- > 10.11.0.0/16 myguest tcp dpt:www to:10.11.0.1 SNAT > tcp -- 10.11.0.0/16 myguest tcp dpt:https > to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > tcp dpt:ssh to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 myguest > tcp dpt:ftp to:10.11.0.1 SNAT tcp -- 10.11.0.0/16 > myguest tcp dpt:5901 to:10.11.0.1 SNAT all -- > anywhere anywhere to:67.xxx.xxx.56 > Chain OUTPUT (policy ACCEPT)target prot opt source > destination DNAT tcp -- anywhere 67.xxx.xxx.56 > tcp dpt:www to:10.11.79.178:80 DNAT tcp -- anywhere > 67.xxx.xxx.56 tcp dpt:https to:10.11.79.178:443 DNAT tcp > -- anywhere 67.xxx.xxx.56 tcp dpt:ssh to: > 10.11.79.178:22 DNAT tcp -- anywhere 67.xxx.xxx.56 > tcp dpt:ftp to:10.11.79.178:21 DNAT tcp -- anywhere > 67.xxx.xxx.56 tcp dpt:5901 to:10.11.79.178:5901 > > > Date: Sat, 14 Sep 2013 17:25:14 +0100 > > Subject: Re: Advanced Network - SNAT not working > > From: [email protected] > > To: [email protected] > > > > Hi Noel, > > > > Can you try using telnet to connect to an external webserver? telnet > > www.google.com 80 > > Can you also clarify: do you see the response packets reach the VR and/or > > on what interfaces? > > > > Thanks, > > Marty > > > > On Saturday, September 14, 2013, Noel Kendall wrote: > > > > > Guest OS cannot receive responses to http GETs from resources on the > > > Internet. > > > Network is advanced, VLAN isolated. > > > What is working: > > > - can browse guest website from internet- can ssh to guest from > internet- > > > can VPN to guest network from internet > > > - network VR can access internet sites no problem > > > What is not working: > > > - guest http traffic to external website gets to VR on internal NIC, > > > packets forwarded to external site via external NIC > > > > > > Response traffic is not seen. Appears to be dropped. > > > Have been looking hard at IPTABLES rules, doing tcpdumps, etc. > > > Am at this point stumped. > > > Any ideas on what could be wrong, or how to determine what could be > wrong? > > > Thanks in advance everyone who tries to help! > > > N. > > > > >
